Fix reported data grid, editor, and filter UX issues#1815
Conversation
…ss it on an outside click
…osing the filter bar
…idden, and show errors inline
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
fd3e206 to
e4728cd
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fd3e2067fb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if !latestRows.columns.isEmpty { | ||
| coordinator.isRebuildingColumns = true | ||
| let savedLayout = coordinator.savedColumnLayout(binding: columnLayout) | ||
| let savedLayout = coordinator.resolvedColumnLayout(binding: columnLayout, liveWidths: liveColumnWidths) |
There was a problem hiding this comment.
Avoid merging default widths over saved layouts
When the grid is remounted with rows already present, such as switching a loaded table from JSON/Structure back to Data after loading a saved layout, makeNSView has already built default-width columns before the table configuration can load the persisted layout. Passing those widths into resolvedColumnLayout here overwrites every saved width with the defaults, so saved column widths appear to reset even though FileColumnLayoutPersister has the right data. Only merge live widths when they are known to come from the same applied layout/table, or skip the merge on the first post-mount reconcile.
Useful? React with 👍 / 👎.
|
|
||
| @ViewBuilder | ||
| private func executionErrorBanner(tab: QueryTab) -> some View { | ||
| if let error = tab.display.activeResultSet?.errorMessage ?? tab.execution.errorMessage { |
There was a problem hiding this comment.
Prefer the contextual execution error
When a multi-statement execution fails, handleMultiStatementError stores the useful Statement x/y failed: ... text in tab.execution.errorMessage but the active error result set only contains error.localizedDescription. Because this coalescing prefers the result-set error, the new inline banner drops the statement number/total and users can no longer tell which statement failed, especially when the first statement fails and there is no useful result-tab context. Prefer the execution error when both are present or put the contextual message on the error result set.
Useful? React with 👍 / 👎.
… statement failed
… and column-layout storage
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5ac5d45ed3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| current: ColumnLayoutTableKey?, | ||
| liveWidths: [String: CGFloat] | ||
| ) -> [String: CGFloat] { | ||
| previous == current ? liveWidths : [:] |
There was a problem hiding this comment.
Don't merge live widths when both layout keys are nil
When both layout keys are nil, this treats the old grid and new grid as the same identity. TableStructureView creates its DataGridView without tableName/tabType, so switching between structure subtabs after saving widths for each subtab will pass the previous subtab's live widths into the newly selected subtab and overwrite any matching column names in that subtab's saved layout. Only preserve live widths when there is a non-nil table key match or add another stable layout identity for non-table grids.
Useful? React with 👍 / 👎.
| onFixWithAI: AppSettingsManager.shared.ai.enabled && tab.tabType == .query | ||
| ? { coordinator.fixErrorWithAI(query: tab.execution.errorQuery ?? tab.content.query, error: error) } |
There was a problem hiding this comment.
Keep Fix with AI available for table filter errors
When a table tab fails because a user-entered raw filter or scoped browse query is invalid, tab.tabType is .table, so this disables onFixWithAI even though handleQueryExecutionError now records the failed SQL in tab.execution.errorQuery. The old failure sheet offered the AI fix for non-restore execution failures regardless of tab type, and this new banner path removes that recovery option for filter errors; gate the button on having a query/error to send rather than on .query only.
Useful? React with 👍 / 👎.
What
Fixes a batch of data grid, editor, and filter UX issues reported after 30 minutes of real use. Most were separate complaints; two of them share a single root cause.
Fixes
Data grid
TabSessionmirror in sync.(connection, table)to connection + database + schema + table (matchingFilterSettingsStorage), so two tables with the same name in different databases no longer overwrite each other's layout.Errors
Editor / filter
Not changed on purpose
(),'') is the standard Xcode / VS Code / DataGrip behavior and was left as-is.Notes
FileColumnLayoutPersisteris now a shared instance; the migration runs only on it, so tests stay isolated from real user defaults.Tests
ColumnLayoutStategeometry tests; updated allColumnLayoutPersistingmocks to the new key API.Verification
swiftlint lint --strictclean on all changed files.