fix(mysql): display all result sets from stored procedures returning multiple result sets#415
Open
debba wants to merge 1 commit into
Open
fix(mysql): display all result sets from stored procedures returning multiple result sets#415debba wants to merge 1 commit into
debba wants to merge 1 commit into
Conversation
…e result sets A single MySQL statement can stream back several result sets — e.g. a CALL to a stored procedure whose body holds multiple SELECTs. The driver consumed the stream with sqlx fetch(), which flattens everything into one columns/rows pair, so only the first result set ever reached the UI. Switch exec_on_mysql_conn to fetch_many(), whose event stream marks the boundary between result sets, and fold it with a new ResultSetCollector (drivers/mysql/multi_result.rs). The first set stays in QueryResult columns/rows; the rest travel in a new optional additional_results field (skipped in JSON when absent, so other drivers and plugins are unaffected). The per-page row cap now applies to each result set independently. On the frontend, execute_query results carrying additional_results are rendered through the existing multi-result tab UI (one tab per result set, labelled via the new editor.multiResult.resultSetPrefix i18n key) instead of the single grid. Known limitation: result sets that produce no rows are dropped — sqlx exposes no column metadata without rows, making them indistinguishable from the trailing OK packet of a CALL. The batch path already receives additional_results but its UI still shows one result per statement. Fixes #414
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (17 files)
Reviewed by nemotron-3-nano-30b-a3b:free · Input: 593.4K · Output: 5.5K · Cached: 111.6K |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #414
Problem
When executing a MySQL statement that returns multiple result sets — typically a
CALLto a stored procedure whose body contains severalSELECTs — Tabularis only displayed the first result set. MySQL Workbench shows all of them.Root cause
exec_on_mysql_connconsumed the wire stream with sqlx'sfetch(), which yields a flat stream of rows with no result-set boundaries: column metadata was taken from the first row and everything was folded into a singleQueryResult { columns, rows }. The data model itself had no way to represent more than one result set per statement. This is the same thing MySQL Workbench handles by loopingmysql_next_result()after enablingCLIENT_MULTI_RESULTS.Fix
Backend
exec_on_mysql_connnow uses sqlx'sfetch_many(), whose event stream interleaves rows with one terminator per result set.drivers/mysql/multi_result.rs(ResultSetCollector) folds that stream back into discrete sets; the per-page row cap now applies to each result set independently.QueryResultgains an optionaladditional_results: Option<Vec<QueryResult>>. The first result set stays incolumns/rows, so every consumer unaware of multi-result statements keeps working unchanged; the field is skipped in JSON when absent, leaving Postgres/SQLite/plugin drivers untouched.Frontend
QueryResultTS type mirrors the new field.execute_queryreturns additional result sets,runQueryrenders them through the existing multi-result tab UI (the one used for multi-statement runs): one tab per result set, labelled "Result 1..N" via the neweditor.multiResult.resultSetPrefixi18n key (added to all 8 locales).activeTable/pkColumns) is intentionally skipped — procedure output is not row-editable.Note on
DELIMITERCreating the procedure still requires the usual client-side
DELIMITERdance (see the snippet above):DELIMITERis not server SQL, it only tells the client's statement splitter to stop splitting on the;inside the procedure body. Tabularis' SQL splitter already supportsDELIMITER //for the MySQL dialect, exactly like themysqlCLI and Workbench — so when testing this PR, remember to wrap theCREATE PROCEDUREinDELIMITER //…END//, otherwise the procedure itself won't be created (that part is expected behaviour, not part of this bug).Testing
drivers::mysql::execute_query) against a live MariaDB with the reproducer procedure from the issue — the call now returns the first set as primary plus 2additional_results; a plainSELECTis byte-for-byte identical to before (no extras, pagination unchanged).cargo test(mysql driver suite): 30 passed, including 7 new unit tests forResultSetCollector(set splitting, per-set truncation, empty-set handling, unterminated stream flush).pnpm test: 2711 passed, including 7 new tests forcreateEntriesFromResultSets.cargo checkclean (no deprecated API),tsc --noEmitclean.Known limitations
CALL. Same pre-existing limitation as a rowless single query.additional_resultsfrom the backend, but its UI still shows one result per statement; expanding extra sets there is left as a follow-up.zh.jsonis missing severaleditor.multiResult.*keys (queryPrefix,viewTabs, …) — only the new key was added here.