M
J
M
RM
user asks for a db -> create a new d1 db via api -> update worker script bindings via api
env.DB.getByShardKey(id: string)
Rwrangler d1 migrations
HMMHHHHHMHMHM
TTT
PRAGMA foreign_keys = OFF;PRAGMA foreign_keys = ONDROP TABLE
I forgot to mention my scenario:
b_ididON DELETE CASCADE ON UPDATE CASCADEIf foreign key constraints are enabled when it is prepared, the DROP TABLE command performs an implicit DELETE to remove all rows from the table before dropping it. The implicit DELETE does not cause any SQL triggers to fire, but may invoke foreign key actions or constraint violations. If an immediate foreign key constraint is violated, the DROP TABLE statement fails and the table is not dropped. If a deferred foreign key constraint is violated, then an error is reported when the user attempts to commit the transaction if the foreign key constraint violations still exist at that point. Any "foreign key mismatch" errors encountered as part of an implicit DELETE are ignored.
PRAGMA defer_foreign_keys = on
TTM
follow up: it seems like bracketing it with PRAGMA defer_foreign_keys = ON; and PRAGMA defer_foreign_keys = OFF; does make it work. I am not familiar enough with arcane SQLite stuff to give a super informed view on whether this should be automatically applied to every migration, but I suspect it might be a good idea - my understanding is that the foreign key constraints will still be checked, but just at the time that the transaction is committed.
TPRAGMA defer_foreign_keys = ONPRAGMA defer_foreign_keys = OFFPRAGMA defer_foreign_keys
JJT
.wrangler/state/v3/d1PRAGMA foreign_keys = OFF;
create table b_temp ...;
drop table b...;
alter table b_tmp rename to b;
PRAGMA foreign_keys = ON;