fix: scope ER diagram, dump and export to the selected database on multi-database connections#346
Merged
Merged
Conversation
On a single MySQL/MariaDB connection that exposes several databases, the ER diagram, the database dump and the CSV/JSON export all ran against the connection's primary database instead of the one the user had selected. The backend resolves the target database from the request, but the frontend never forwarded the selected database, so it kept falling back to the first one. ER diagram: - Forward the selected database to get_schema_snapshot (the MySQL driver treats the schema argument as the database name), so each database renders its own tables. - Give every diagram window a unique label per connection/database/schema and focus an existing one instead of silently reusing the first window. Dump: - Pass the selected database to dump_database so the pool connects to it and unqualified statements (SHOW CREATE TABLE, SELECT * FROM ...) hit the right database. - Reload the target database's tables when the dialog opens so the table list reflects that database rather than a stale or wrong one. Export: - Pass the selected database to export_query_to_file, resolving it from the tab schema and falling back to the active database (matching how execute_query already resolves it).
This was referenced Jun 22, 2026
Code Review SummaryStatus: 4 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (8 files)
Fix Link |
Code Review SummaryStatus: 4 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (8 files)
Fix LinkFix these issues in Kilo Cloud Reviewed by kimi-k2.6-20260420 · Input: 132.9K · Output: 31K · Cached: 1.4M |
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.
What this fixes
When a single MySQL/MariaDB connection has several databases selected, a few features kept operating on the connection's primary database (the first one) instead of the database you actually picked:
Table 'first_db.some_table' doesn't exist([Bug]: Database Export/Dump Context Switching Failure in Multi-Database Environment #334).The common cause is the same: the backend resolves the target database from the request, but the frontend never sent which database was selected, so every call fell back to
database.primary().Changes
ER diagram
get_schema_snapshot. The MySQL driver already treats theschemaargument as the database name, so each database renders its own schema. This is centralized in a smallresolveDiagramSchemahelper (with unit tests) and leaves PostgreSQL untouched, since it always sends an explicit schema.Dump
dump_databasenow receives the selected database and binds the pool to it, so unqualified statements (SHOW CREATE TABLE,SELECT * FROM ...) run against the right database.Export
export_query_to_filenow receives the selected database. The frontend resolves it from the tab's schema and falls back to the active database, matching howexecute_queryalready resolves it (so it works whether you export a table tab or a console result after switching databases).The new backend parameters are all optional, so PostgreSQL and SQLite behavior is unchanged.
Testing
cargo checkpasses.tsc --noEmitpasses.resolveDiagramSchema).Closes #345
Closes #334