fix(datagrid): type filter values from the table's columns before its first rows load - #2737
Merged
Merged
Conversation
… first rows load Claude-Session: https://claude.ai/code/session_01JKFSBk6YwDemnkbQnyc2xz
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.
A filter value on a text column went out as a number when the table's first page had not loaded yet. With
code = 0123, a table that opened with that filter applied sentWHERE code = 0123instead ofWHERE code = '0123'. PostgreSQL rejects that, and MySQL compares numerically, so'00123'matches as well. A foreign key jump into the current tab did the same. The Cloudflare R2 SQL review in #2030 found this, because R2 SQL has no implicit conversions and fails the query outright.Cause
Filter SQL took its column types only from the tab's loaded rows. Before any rows arrived,
FilterSQLGeneratorhad no types and guessed from the value's text. The schema cache (SchemaColumnStore) held column names and primary keys but no types. The first-load step fetched the schema only for a default sort, hidden columns or a restored page, never for filters. The foreign key jump into the current tab skipped the first-load step altogether and built its SQL from the empty row buffer.Fix
SchemaColumnStore.Entryis now a struct that also holds each column'sColumnType. The type comes fromColumnTypeClassifier, the same classifier the result path, MCPbrowse_tableand the foreign key lookup use.MainContentCoordinator.queryColumns(for:)returns the loaded rows' columns and types once rows exist, and the schema's before that.ColumnTypeClassifierstrips trailingUNSIGNED,SIGNEDandZEROFILL. MySQL's catalog spells a columnINT UNSIGNEDorINT(10) UNSIGNED ZEROFILL, while its result metadata saysINT. Without this, the catalog spelling fell through to text, and this fix would have started quoting values on common unsigned id columns on first load.Behaviour changes
Verification
FilterTypingBeforeFirstLoadTests:0123on first load, andTRUEstays'TRUE';123unquoted;FKNavigationTests: a jump into the current tab types0123from the target table's schema.SchemaColumnStoreTests: entries built from fetched columns, aligned types, and a column name the table does not have.ColumnTypeClassifierTests:INT UNSIGNEDand the other trailing attributes.swiftlint --stricton the 16 changed paths: 0 violations. That includes one import-order finding that was already inColumnTypeClassifierTests.Still untyped: a first load with an empty buffer and no schema. That only happens when an unfiltered first load failed, the metadata fetch failed, or the engine's
fetchColumnsreturns nothing. The value is then guessed from its text, as before.No UI automation: the defect is in the SQL the first load sends, which the unit suites check directly, and a UI test would need a server-backed table with a text column holding numeric-looking values.
https://claude.ai/code/session_01JKFSBk6YwDemnkbQnyc2xz