Conversation
|
can't a migration fix existing tables? |
|
Yep, fair point. Added two migrations (split DML/DDL like 304a32906234 does for cockroach): the first renumbers any existing ids above 2^53 down into the safe range and repoints the FKs, the second swaps the id defaults from unique_rowid() to sequences. Also found why the cockroach CI job went red: sql_sequence_cached gives each connection its own block of ids so they stop following insertion order, which broke the vendor sort test. Switched to plain sql_sequence and verified the whole thing against a real cockroach v23.1.2, old huge-id rows and all. |
a796706 to
0e3c037
Compare
|
Rebuilt the branch on current master, my follow-up commit had dragged in a pile of unrelated master changes (that's what tripped the translations guard and the conflict), so the PR is back to just the cockroach change. Also chained the migrations after the new tags one and made the renumbering repoint tag.spool_id/filament_id as well. Left the tag ids themselves alone since that table isn't in a release yet, happy to add it if you'd rather. |
Fixes #797.
CockroachDB expands SERIAL primary keys to
DEFAULT unique_rowid(), which produces 64-bit IDs. JavaScript numbers are only exact up to 2^53, so the web UI rounds them: the database hands out vendor ID 1134663890672549889, the UI sends back 1134663890672549900, and every follow-up request 404s.This asks CockroachDB for sequence-backed SERIAL instead (
serial_normalization=sql_sequence_cached), so tables are created with ordinary small IDs. It goes in as a per-connection server setting rather than a SET statement because it has to be in force when the CREATE TABLE DDL runs, and the Alembic migrations build their connection through the sameDatabase.connect().One catch worth knowing about:
serial_normalizationonly applies at table creation time, so this fixes fresh databases. An existing CockroachDB install already hasunique_rowid()baked into its column defaults and rows with 64-bit IDs that can't be shrunk after the fact, so recreating the database is the way out there.Added two unit tests that check the setting is passed for cockroachdb and not for the other backends; they and the existing suite pass. I don't have a live CockroachDB here, so the integration side is on the CI cockroachdb job.