Chat2DB Edition
Chat2DB Community
User Problem
SQL execution records were displayed only in oldest-first order, so the newest output was always at the bottom. The Output view also needed a reliable, explicit follow setting: users must be able to browse earlier execution records without that scrolling action silently disabling follow mode.
Concrete Use Case
A user repeatedly executes SQL while monitoring the Output tab. They need to choose whether the newest execution appears at the top or bottom, keep that ordering preference across sessions, explicitly enable or disable follow mode, and freely scroll through history without changing the follow setting.
Product Area
SQL editor
Proposed Outcome
- Keep Output free of a persistent toolbar and expose its actions through the existing right-click menu.
- Group the menu into three levels: copy; ordering and follow; destructive clear.
- Provide one ordering item that displays and toggles between "Oldest first" and "Newest first".
- Keep oldest-first as the default and remember the selected ordering preference per runtime.
- In newest-first mode, reverse complete execution groups while preserving chronological statement order inside each execution.
- Follow the bottom edge in oldest-first mode and the top edge in newest-first mode.
- Treat follow-latest as an explicit on/off setting. Manual scrolling and ordering changes must not alter it.
- Show a check while follow mode is enabled and an order-aware edge arrow while it is disabled.
- While follow mode is enabled, keep the latest edge aligned after execution-record and layout-size updates.
Implemented in #1936
- Added persisted execution-group ordering and one-click ordering changes in the Output context menu.
- Added a true follow-latest toggle with visible state and scroll-independent behavior.
- Grouped the context menu as copy; ordering/follow; clear.
- Removed the temporary always-visible ordering toolbar and resume button.
- Cancelled and identity-guarded deferred result-grid resizing so repeated page refreshes cannot call
resize() on a released VTable instance.
Verification
yarn test:execution-console passed.
yarn test:sql-execution-log passed.
yarn test:search-result-tab-selection passed.
yarn lint:eslint passed with zero warnings.
yarn build:web:community passed.
git diff --check passed.
- The local Community runtime hot-compiled successfully, and both the frontend and proxied backend health endpoints returned HTTP 200.
yarn test:i18n reports only the existing es-ES/setting.ts and ko-KR/setting.ts source-hash baseline; all changed common.ts translations and hashes pass.
Alternatives Considered
An always-visible segmented control and a separate resume button were implemented initially, but they consumed Output space and duplicated the existing context-menu interaction. Deriving follow state from the current scroll position was also rejected because browsing history is not the same action as changing a persistent user setting.
Contribution
I can help test the change
Submission Checklist
Chat2DB Edition
Chat2DB Community
User Problem
SQL execution records were displayed only in oldest-first order, so the newest output was always at the bottom. The Output view also needed a reliable, explicit follow setting: users must be able to browse earlier execution records without that scrolling action silently disabling follow mode.
Concrete Use Case
A user repeatedly executes SQL while monitoring the Output tab. They need to choose whether the newest execution appears at the top or bottom, keep that ordering preference across sessions, explicitly enable or disable follow mode, and freely scroll through history without changing the follow setting.
Product Area
SQL editor
Proposed Outcome
Implemented in #1936
resize()on a released VTable instance.Verification
yarn test:execution-consolepassed.yarn test:sql-execution-logpassed.yarn test:search-result-tab-selectionpassed.yarn lint:eslintpassed with zero warnings.yarn build:web:communitypassed.git diff --checkpassed.yarn test:i18nreports only the existinges-ES/setting.tsandko-KR/setting.tssource-hash baseline; all changedcommon.tstranslations and hashes pass.Alternatives Considered
An always-visible segmented control and a separate resume button were implemented initially, but they consumed Output space and duplicated the existing context-menu interaction. Deriving follow state from the current scroll position was also rejected because browsing history is not the same action as changing a persistent user setting.
Contribution
I can help test the change
Submission Checklist