cheers - btw #wrangler might be a better place to ask folks if they've run into this issue
cheers - btw #wrangler might be a better place to ask folks if they've run into this issue
CGreat, thanks for the tip
COnly just realised I posted this in the D1 channel - sorry! Must've hit the wrong tab when aiming for wrangler (immediately above it)
Mnah the idea is to keep them around so you can setup the project from scratch
Md1 keeps track of what you're already applied, but if you made a new db you could apply all migrations from the start and have a working copy
Myep
CThey announced in a blog post that paid plan will be getting 1GB max. Only ETA is 
MON DUPLICATE KEY isn’t supported by D1’s query engine (SQLite) - use UPSERT or INSERT OR IGNORE instead: https://stackoverflow.com/a/4330694/556573Stack Overflow
http://en.wikipedia.org/wiki/Upsert
Insert Update stored proc on SQL Server
Is there some clever way to do this in SQLite that I have not thought of?
Basically I want to update three out of four co...
Insert Update stored proc on SQL Server
Is there some clever way to do this in SQLite that I have not thought of?
Basically I want to update three out of four co...
AQuick question: when applying migrations to production databases, what are the most common ones that cause (or is there a list) requests to be held while the migration applies? I know the backup is one, but for example, are
ALTER TABLE likely to also cause requests to be held while it applies?AAnd presumably things like creating new tables and inserting data won't cause such problems
AAnd similarly to alter table, adding indexes would possibly be one?
CD1 maxes out at 100 MB
CI've hit that before, it's just wayy too much for wrangler to handle/split properly, and even if you get past it, my experience was trying to insert any mass amount of data (like 20-40 MB in my case, was large rows) to the new experimental backend would just fail with a d1 error. Hopefully will improve/make it easier to import lots of data eventually, but it's still alpha
Ktable_list, table_info and table_xinfo workKNo other pragmas are currently allowed, but if you have a valid use-case for any others then open an issue on https://github.com/cloudflare/workerd/issues/new/choose for it to be considered.
KSure - I'm not saying there's any reason the ones you listed shouldn't be allowed, I don't represent the Workers team. They just haven't currently allowed them, so that's why you get that error.
LI think it is the dashboard. I had a similar issue with a CURRENT_TIMESTAMP DEFAULT value. When in code worked fine (the proper date was inserted) but when adding records in dashboard I got the text 'CURRENT_TIMESTAMP '
MBug report: the dashboard table viewer munches tables which have generated columns
to reproduce:
to reproduce:
Mif you run
SELECT * FROM example with wrangler or the dashboard console, it works as expected, but the table viewer shows this:
M99% sure this is happening because the dashboard appears to use the
table_info pragma to discover the structure of the table, when, for historical reasons, that pragma doesn't show generated columns - table_xinfo must be used instead. (see https://www.sqlite.org/gencol.html 2.3 #9)
Myeah, dashboard bug - default values render weirdly
Mcheers for the bug report + the fix 
MI'm having trouble getting foreign key constraints to work. I know with SQLite you need to run
PRAGMA foreign_keys=on on every connection, but this seems to always be a no-op. Anyone else run into this before?LThey worked for me. What makes you think they didn't work for you and how were they created? I think in sqlite you can only create them within CREATE TABLE and not with ALTER TABLE ADD CONSTRAINT .
MYes, all of them were created within the CREATE TABLE statements. But the DB happily accepts garbage data which should be caught by foreign key constraints. Like I said, I couldn't even get the pragma turned on to begin with.
LHmm, to be precise the foreign key constraints screamed at me when trying to drop and recreate a table (referenced by ) but I never really tried to add data violating the constraints. So my anecdotal example might not be relevant to you
MWere you using the alpha backend? One difference I just found is that for some reason, the alpha backend defaults to
foreign_keys=1, while the beta backend defaults to foreign_keys=0.Mactually that means that foreign keys work exactly as intended on the alpha backend, which means that the only thing left to figure out is how to set
foreign_keys=1 on the beta backend. It's tricky because that's per-SQLite connection, but the D1 API doesn't have a concept of a connectionLYes, I was on the alpha backend
LI wonder if you can use a db.batch in your worker and have your pragma foreign key as the first statement
MI was going to try a workaround like that, but it's still not ideal because I can't use prepared statements that way
MCF must have somehow set foreign_key default on for the alpha backend, so it'd be really nice if they could expose an option to allow that same behavior for the beta backend
MIf I have some extra time this afternoon I might file an issue on the github repo
Kforeign key default is set on the experimental backend 
Kor it might be soon
Kit was committed to workerd 2 weeks ago so it'll be in the next release if it hasn't already released
MRight, for the experimental backend:
- all queries run inside a transaction
- You can’t enable foreign keys via the PRAGMA inside that context
- We are making foreign key enforcement the default
- You can relax it with
PRAGMA defer_foreign_keys = on - Docs coming very very soon
MThank you! I'm glad this is on the radar and coming soon.
MWIP docs: https://silverlock-d1-foreign-keys.cloudflare-docs-7ou.pages.dev/d1/learning/foreign-keys/
Need to write up FK actions, add basic schema examples (how to define fkeys between tables), and how to handle errors/resolve FK issues - before I publish it proper.
Need to write up FK actions, add basic schema examples (how to define fkeys between tables), and how to handle errors/resolve FK issues - before I publish it proper.
