fix: SQLite date-like column edits producing NaN - #1550
Conversation
SQLite columns declared as date/datetime/timestamp get NUMERIC affinity, so Studio grouped them as numeric and coerced date-string edits to NaN. - Introspect date-like declared types with group "string" so their values are edited and stored as text, matching other SQLite tools. - Never coerce to NaN: NumericInput and coerceToValue only produce a number when the input actually parses as one, otherwise the raw text is kept (SQLite NUMERIC affinity stores non-numeric text as TEXT). Fixes #1361 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughSQLite introspection now assigns date-like NUMERIC-affinity columns to the string datatype group. Numeric conversion and input submission preserve non-numeric text instead of producing 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
|
Compute preview deployed. Branch: |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@data/sqlite-core/datatype.ts`:
- Line 39: Update DATE_LIKE_DECLARED_TYPE_REGEX to match DATE or TIME as
declared-type tokens rather than arbitrary substrings, preventing types such as
CANDIDATE from being classified as strings. Add a regression case covering
CANDIDATE and preserve date/time matching behavior for valid declared types.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 60c7f7af-7e8e-4926-8d1e-6314a06e0878
📒 Files selected for processing (13)
.changeset/sqlite-date-like-columns-text.mdArchitecture/cell-editing.mdFEATURES.mddata/sqlite-core/adapter.test.tsdata/sqlite-core/adapter.tsdata/sqlite-core/datatype.test.tsdata/sqlite-core/datatype.tsdata/sqlite-core/introspection.test.tslib/conversionUtils.test.tslib/conversionUtils.tsui/studio/input/NumericInput.test.tsxui/studio/input/NumericInput.tsxvitest.config.ts
The date-like check used a bare /DATE|TIME/ substring match, so NUMERIC-affinity declared types like CANDIDATE, DATED, or RUNTIME were misclassified as date-like. Use word-boundary token matching instead, which still covers modifiers like DATETIME(6) and TIMESTAMP WITH TIME ZONE, and add near-miss regression cases. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Fixes #1361
Root cause
SQLite reduces declared column types to affinities;
datetime/date/timestampget NUMERIC affinity, which the adapter mapped to the UI'snumericinput group. Numeric cells then coerced input unconditionally withNumber(...)in two places (NumericInput's save handler andcoerceToValue's numeric branch), so a value like2021-11-01 22:30:00becameNaNand was written.Fix — never write NaN
string, so Studio edits/stores them as text (SQLite's own affinity conversion still applies on write).coerceToValueandNumericInputonly coerce when the input actually parses as a number; otherwise the raw text passes through — matching SQLite's NUMERIC-affinity semantics where non-numeric text is stored as TEXT.Verification
NaNbeing submitted), including an end-to-end update test assertingtypeof(datetime) = 'text'.pnpm test: 928 tests passing; typecheck/lint clean; changeset included; staging rule documented inArchitecture/cell-editing.md.Note: header badges still show the NUMERIC affinity for these columns — displaying declared types is #1386's scope.
🤖 Generated with Claude Code