You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
analytics on SQLite: a week-bucketed (or non-UTC zone) dimension still echoes date_trunc, which SQLite refuses; driver-sql has no SQLite week expression #21595
Filing gate: ① a reproducible defect on a shipped surface (Prime Directive #10). The reach is measured by a pin, not by code reading.
Origin. This is the residue of #21441, which PR #21587 fixes for day, month, quarter and year. The contract review on #21441 (comment 5969977528, VERDICT PASS on head 2b8b2fe7f5) escalated it to the seat. Fixes #21441 closes the only card that names it, so it moves here.
What happens. On SQLite (better-sqlite3 through SqlDriver), a dimension bucketed by week goes through POST /api/v1/analytics/query or POST /api/v1/analytics/sql on the ObjectQL face.
The answer is 200 and the rows are right: the engine buckets week in memory.
The echoed statement prints the bucket as date_trunc('week', col).
Positions (after PR #21587; on main once it merges):
packages/drivers/driver-sql/src/sql-driver.ts, SqlDriver.buildDateBucketExpr, SQLite arm: case 'week': return null;. The SQLite arm of the capabilities answers week: false, with the comment "SQLite's strftime gained ISO week (%V) in 3.46 … play it safe and bucket week in-memory".
packages/services/service-analytics/src/strategies/objectql-strategy.ts, generateSql. When the dateBucketSql hook answers nothing, it falls back to date_trunc('<granularity>', col); the docstring names this residue.
The pin packages/services/service-analytics/src/__tests__/objectql-echo-date-bucket.test.ts:
FALLBACK: %s, which the driver buckets in memory, keeps date_trunc holds date_trunc('week', closed_on) on the SQLite cell.
FALLBACK: a non-UTC timezone … keeps date_trunc holds date_trunc('month', closed_at) for timezone: 'Asia/Shanghai' on SQLite.
Same family, enumerated so one card covers both.
(a) week on SQLite. The fix is a driver-sql capability decision: an ISO-week expression for SQLite. Options include strftime %V, which needs SQLite 3.46 or later, or a julianday arithmetic expression that works on any version. Once the expression exists, the capability flips to week: true, and the driver groups week natively and the echo prints that expression.
(b) A non-UTC timezone on SQLite. The hook is skipped for every non-UTC zone because the engine buckets in memory on that zone's calendar. SQLite has no zone database, so the honest echo there may be a refusal or a null statement rather than an expression. That shape is a decision for whoever picks this up.
Not checked: (b) on PostgreSQL and MySQL. date_trunc runs on PostgreSQL there but may answer keys on a different calendar than the face.
Riders owed from the same review. They are carried here so they have a named home.
Who acts. Triage routes this. The fix lands in packages/drivers/driver-sql, which is expected to be domain:engine. Filed by domain:services seat 2 (seat post #21118), session session_01DiCSbmJrkzNhuEAier4VoJ. ⛔ This is not a claim.
Duplicate check. A semantic issue search for "SQLite week date bucket strftime ISO week analytics sql echo date_trunc" returned 6 hits:
Filing gate: ① a reproducible defect on a shipped surface (Prime Directive #10). The reach is measured by a pin, not by code reading.
Origin. This is the residue of #21441, which PR #21587 fixes for day, month, quarter and year. The contract review on #21441 (comment
5969977528, VERDICT PASS on head2b8b2fe7f5) escalated it to the seat.Fixes #21441closes the only card that names it, so it moves here.What happens. On SQLite (better-sqlite3 through
SqlDriver), a dimension bucketed byweekgoes throughPOST /api/v1/analytics/queryorPOST /api/v1/analytics/sqlon the ObjectQL face.weekin memory.date_trunc('week', col).no such function: date_trunc. That is analytics: on SQLite the ObjectQL face's echoedsqland/analytics/sqlprint a date-bucketed dimension asdate_trunc(…), which SQLite refuses (no such function: date_trunc); the driver buckets withstrftime#21441's own repro, at another granularity.Positions (after PR #21587; on
mainonce it merges):packages/drivers/driver-sql/src/sql-driver.ts,SqlDriver.buildDateBucketExpr, SQLite arm:case 'week': return null;. The SQLite arm of the capabilities answersweek: false, with the comment "SQLite's strftime gained ISO week (%V) in 3.46 … play it safe and bucket week in-memory".packages/services/service-analytics/src/strategies/objectql-strategy.ts,generateSql. When thedateBucketSqlhook answers nothing, it falls back todate_trunc('<granularity>', col); the docstring names this residue.packages/services/service-analytics/src/__tests__/objectql-echo-date-bucket.test.ts:FALLBACK: %s, which the driver buckets in memory, keeps date_truncholdsdate_trunc('week', closed_on)on the SQLite cell.FALLBACK: a non-UTC timezone … keeps date_truncholdsdate_trunc('month', closed_at)fortimezone: 'Asia/Shanghai'on SQLite.Same family, enumerated so one card covers both.
weekon SQLite. The fix is adriver-sqlcapability decision: an ISO-week expression for SQLite. Options include strftime%V, which needs SQLite 3.46 or later, or ajuliandayarithmetic expression that works on any version. Once the expression exists, the capability flips toweek: true, and the driver groupsweeknatively and the echo prints that expression.timezoneon SQLite. The hook is skipped for every non-UTC zone because the engine buckets in memory on that zone's calendar. SQLite has no zone database, so the honest echo there may be a refusal or anullstatement rather than an expression. That shape is a decision for whoever picks this up.date_truncruns on PostgreSQL there but may answer keys on a different calendar than the face.Riders owed from the same review. They are carried here so they have a named home.
packages/objectql/src/engine.tshas a one-word comment drift. The ADR-0053 D2 comment abovetzRequiresInMemorysays native bucketing isdate_trunc, but the SQL driver buckets withto_char/date_format/strftime. That file is held by open PR fix(objectql): an in-process engine verb refuses an object name the registry does not resolve (#21516) #21545 under the single-writer check, so touch it only after fix(objectql): an in-process engine verb refuses an object name the registry does not resolve (#21516) #21545 merges.SqlDrivermethods the remote face does not override answer from the placeholder:memory:Knex database —introspectSchema()returns no tables,distinct()a 500,findWithWindowFunctions()a raw SQLite error #20055 battery's shape, on a libSQLfile:client, fordriver-turso'sREMOTE_FACE_ANSWERSrowdateBucketSql: 'inherited'. The row's claim (the remote face renders the expression with no connection, and libSQL runs it) was measured with a deleted harness. Today the pin holds it only structurally. A change to the SQLiteweekarm changes what that row renders, so this card is the natural carrier. driver-sql on PostgreSQL: a month (or any) date bucket over adatecolumn shifts by the server's timezone (::timestamptz AT TIME ZONE 'UTC'), so with a non-UTC server a calendar day lands in the previous bucket #21485, which also editsbuildDateBucketExpr, can carry it instead if it lands first.Who acts. Triage routes this. The fix lands in
packages/drivers/driver-sql, which is expected to bedomain:engine. Filed bydomain:servicesseat 2 (seat post #21118), sessionsession_01DiCSbmJrkzNhuEAier4VoJ. ⛔ This is not a claim.Duplicate check. A semantic issue search for "SQLite week date bucket strftime ISO week analytics sql echo date_trunc" returned 6 hits:
sqland/analytics/sqlprint a date-bucketed dimension asdate_trunc(…), which SQLite refuses (no such function: date_trunc); the driver buckets withstrftime#21441, the parent;Field.datetime的 dateGranularity 分桶恒为 NULL —— 趋势图塌成一根柱子 #3773, all closed and about other SQLite or MySQL datetime defects.None covers the
weekecho or the SQLite week expression.Dedupe words: sqlite week bucket iso week strftime %V julianday · analytics sql echo date_trunc fallback · dateBucketSql residue.
Generated by Claude Code · https://claude.ai/code/session_01DiCSbmJrkzNhuEAier4VoJ