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
Residual scope after PR #19 (reopened by the spec owner -- the original text pre-commits against closing on a lossy implementation)
What landed (v0.2, PR #19): S6.1 "Response value encoding" emission MUSTs keyed on the STORED value; conformance cases V-1..V-4 writing values as SQL literal text so the driver path is what gets tested; fixture columns with affinity rationale.
What remains open -- the driver-layer half: both Cloudflare reference servers provably FAIL V-1 today, and cannot be fixed at the encoding layer:
D1: the API does not surface bigints ("BigInts are not currently supported in the API yet").
Durable Objects: SqlStorageValue is ArrayBuffer | string | number | null; the storage docs state a large int64 "may be less precise than your original number" on retrieval.
This issue closes when either workerd#4195 (or an equivalent API) ships and both reference servers pass V-1 with real 64-bit values, or a deliberate spec-owner ruling downgrades the reference servers' V-1 status permanently (not the default -- the reference servers exist to demonstrate conformance).
Guard unchanged from the original: do not close this with an implementation that still loses the value.
Residual scope after PR #19 (reopened by the spec owner -- the original text pre-commits against closing on a lossy implementation)
What landed (v0.2, PR #19): S6.1 "Response value encoding" emission MUSTs keyed on the STORED value; conformance cases V-1..V-4 writing values as SQL literal text so the driver path is what gets tested; fixture columns with affinity rationale.
What remains open -- the driver-layer half: both Cloudflare reference servers provably FAIL V-1 today, and cannot be fixed at the encoding layer:
SqlStorageValueisArrayBuffer | string | number | null; the storage docs state a large int64 "may be less precise than your original number" on retrieval.SELECT CAST(col AS TEXT)).This issue closes when either workerd#4195 (or an equivalent API) ships and both reference servers pass V-1 with real 64-bit values, or a deliberate spec-owner ruling downgrades the reference servers' V-1 status permanently (not the default -- the reference servers exist to demonstrate conformance).
Guard unchanged from the original: do not close this with an implementation that still loses the value.