fix(tables): filtering on built-in columns (createdAt/updatedAt/id) returns no rows - #6114
fix(tables): filtering on built-in columns (createdAt/updatedAt/id) returns no rows#6114serhiizghama wants to merge 2 commits into
Conversation
…row columns id, createdAt and updatedAt are stored as top-level columns on user_table_rows, not inside the data JSONB, but the filter builder extracted them via data->>'field' (always NULL, so filters matched nothing) and the sort builder referenced user_table_rows.createdAt, which folds to a non-existent createdat. Route both through a shared BUILTIN_COLUMNS map that resolves the wire name to the real column (created_at/updated_at) and type; equality on a built-in compiles to =/IN since JSONB containment can't touch a real column. A user column with the same key still wins.
Range/equality/membership on id, createdAt, updatedAt now reference the physical column; a user column with a colliding key still falls back to the JSONB path.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryMedium Risk Overview Introduces a If a user-defined column shares the same id (e.g. a custom Reviewed by Cursor Bugbot for commit 1c88779. Bugbot is set up for automated code reviews on this repo. Configure here. |
Greptile SummaryCorrects filtering and sorting for built-in table-row fields.
Confidence Score: 5/5The PR appears safe to merge, with built-in filtering and sorting now targeting the correct physical columns. The fixed identifier map selects the schema-backed columns, filter values remain parameterized, date comparisons receive the expected timestamp cast, and user-defined colliding columns retain the documented precedence.
|
| Filename | Overview |
|---|---|
| apps/sim/lib/table/sql.ts | Routes built-in filters and sorts through a fixed physical-column map with bound values and type-aware timestamp casts; no actionable defect identified. |
| apps/sim/lib/table/tests/sql.test.ts | Adds focused SQL-generation tests for built-in date/id filters, sorting, and user-column shadowing. |
Reviews (1): Last reviewed commit: "test(tables): cover built-in column filt..." | Re-trigger Greptile
Closes #5920. Filtering on the built-in columns always came back empty. They live as real top-level columns on
user_table_rows, but the filter builder pulled them out of thedataJSONB —data->>'createdAt'is always NULL, so a numeric-coerced timestamp matched nothing and a plain date string hit the "requires a number" error (the unknown column type fell back to a numeric cast).Routed built-in columns through a small
BUILTIN_COLUMNSmap that resolves the wire name to the physical column and type, so a filter referencesuser_table_rows.created_atdirectly. Equality compiles to=/INinstead of JSONB containment (which can't touch a real column), and date columns cast the value totimestamptzlike the existing data-column path. A user column with a colliding key still shadows the built-in.The sort builder had the mirror image of the same bug: its
createdAt/updatedAtcase emitteduser_table_rows.createdAt, which Postgres folds tocreatedat(no such column), andidfell through todata->>'id'. Both now go through the same map and referencecreated_at/updated_at/id.Added tests for the built-in filter/sort SQL and the user-column shadow case.
bun run type-checkis clean and the table lib suite (491 tests) passes.