What
After a successful inline grid edit, the grid empties. The UPDATE's own result, which carries no rows, replaces the SELECT result the user was looking at.
Where
src/hooks/use-query-execution.ts:613
result: isExplain ? null : resultData, // Don't show EXPLAIN as results
resultData is assigned to the tab for every non-EXPLAIN execution. An inline edit runs its UPDATE through the same executeQuery, so the empty result set lands on the tab that was showing the rows.
Observed
Edit a cell, apply, the statement succeeds. The grid then reads "Query returned no data" and Export drops to 0 rows. Re-running the original SELECT brings the data back with the change in place.
Why this matters
The user cannot see the change they just made, and the state looks like the edit destroyed the rows. Export in particular is misleading: it silently exports nothing.
Suggested direction
Either re-run the tab's query after a successful apply, or keep the tab's result and apply the change to the rows in memory. The second avoids a round trip but has to handle the case where the row no longer matches the query's filter.
Related
Depends on the same code path as the wrong-table UPDATE and the silent failure, both filed separately.
What
After a successful inline grid edit, the grid empties. The UPDATE's own result, which carries no rows, replaces the SELECT result the user was looking at.
Where
src/hooks/use-query-execution.ts:613
resultDatais assigned to the tab for every non-EXPLAIN execution. An inline edit runs its UPDATE through the sameexecuteQuery, so the empty result set lands on the tab that was showing the rows.Observed
Edit a cell, apply, the statement succeeds. The grid then reads "Query returned no data" and Export drops to 0 rows. Re-running the original SELECT brings the data back with the change in place.
Why this matters
The user cannot see the change they just made, and the state looks like the edit destroyed the rows. Export in particular is misleading: it silently exports nothing.
Suggested direction
Either re-run the tab's query after a successful apply, or keep the tab's result and apply the change to the rows in memory. The second avoids a round trip but has to handle the case where the row no longer matches the query's filter.
Related
Depends on the same code path as the wrong-table UPDATE and the silent failure, both filed separately.