S
<
11
G
SELECT statements to use env.DB.withSession() but get this error:Read replication in the D1 setting, any clue what's wrong?
Jenv.DB
PPP
LPRAGMA table_info(table_name) and show us the output? I'm wondering if the table was originally created with a different primary key and changed your code to something like, CREATE TABLE IF NOT EXISTS... with the primary key that you now think is the primary key but it actually isn't.
JP
L
NOT NULL. https://sqlite.org/quirks.html#primary_keys_can_sometimes_contain_nullsLThe value of an INTEGER PRIMARY KEY column must always be a non-NULL integer because the INTEGER PRIMARY KEY is an alias for the ROWID. If you try to insert a NULL into an INTEGER PRIMARY KEY column, SQLite automatically converts the NULL into a unique integer.
DD
GD
GGD
depends on the implementation on the backend i suppose. in the way i understand how the sqlite instances are stored in a DO (largely based on this), i imagine it would be easier to save the d1 row in its entirety to "cold" storage (which essentially r2 would be) than to first read it to in memory, then iterate over each row in the db, export it etc.
LJDGL
DLDD
N
packages/db where a wrangler.jsoncapps/server with another wrangler.jsoncpackages/api(orpc) which is attached to the server app. In my web app, i was trying to perform some queries(todos and authentication with better-auth) but was getting internal error code with some logs saying the table could not be found which was weird. after days of debugging, i just found out that a local db file also being created inside apps/server/.wrangler. so wrangler was using the local db inside the server directory instead of the one in db.packages/db instead?--persist-to flag like this "dev": "wrangler dev --persist-to ../../packages/db/.wrangler/state"
L
RPRAGMA defer_foreign_keys = true. I could then confirm that all data was identical between X and X_old, then drop X_old. But now this doesn't work and I get the error FOREIGN KEY constraint failed: SQLITE_CONSTRAINT [code: 7500]. I see that D1 now updates the references on Y and Z so that they point at X_old instead of the newly created version of X. If I do the same copy/rename trick on Y and Z, then my new X ends up referencing Y_old and Z_old. I can't figure out how to get a clean reset with the new X, Y, and Z pointing to each other and nothing pointing to the old tables so that they can be deleted. Is there a way to disable the auto-renaming of foreign key constraints so that the previous behavior would work?RJ
WW
D
RLL
ZZL
If you notice anything, please reach out.G
O
Home to Wrangler, the CLI for Cloudflare Workers® - cloudflare/workers-sdk
O
SELECTRead replicationPRAGMA table_info(table_name)CREATE TABLE IF NOT EXISTS...NOT NULLpackages/dbpackages/dbapps/serverpackages/apiapps/server/.wrangler--persist-to"dev": "wrangler dev --persist-to ../../packages/db/.wrangler/state"PRAGMA defer_foreign_keys = trueFOREIGN KEY constraint failed: SQLITE_CONSTRAINT [code: 7500]