Is there a way I can test how a lookup would be counted during this time?
Is there a way I can test how a lookup would be counted during this time?
MNot yet, per the docs: https://developers.cloudflare.com/d1/platform/pricing/
- we are working on it. Won’t be within the next month. Focusing on Time Travel and stability.
While in public Alpha, D1 is currently free to use on all Workers plans. Refer to the our recent announcement) for more information.
MKeep in mind that you would need to serve 25 billion requests with that query pattern to exhaust the 50B included read units. 25B / 30 / 86400 = 9600+ requests/sec, 24/7/30.
MI did it manually, but if you do find a good secure tool to use, hit me up
MWe're planning on removing the "Mapping SQL input into an array of statements" step from wrangler fwiw
MMerged the PR + cleaned up migrations output a bit
MD1's experimental backend runs your SQL within a transaction automatically fwiw
Moh nah I mean when you run
npx wrangler d1 execute or npx wrangler d1 migrations apply - the SQL executes within a transaction
MWe’re looking at alternatives that make it easier to interleave SQL and JS. We can’t give you a specific timeline. The blog highlights what we are focusing on in the near term for D1.
Mi think we borrowed that from the cf v4 api
MAnyone else getting this when trying to use the experimental backend for new D1 databases?
not authorized to use function: strftimeMWorks locally and worked with old DBs. Tried to create a copy of my DB with the experimental backend and I'm now getting this error.
Mcan you file an issue against workerd? https://github.com/cloudflare/workerd/issues
we're gradually allow-listing functions and may have missed a few
we're gradually allow-listing functions and may have missed a few
MWill do that right now!
MAny expectation on how long that'll take to make it in? Curious if I should roll back to my old DB and write batching functions instead (which is why I was trying a move to the new backend).
IAny specific reasoning why
CURRENT_TIMESTAMP works when using it as the default for a column in the schema, but fails when used in any kind of statement (with a "not authorized")?ITo note, a
datetime('now') works fine in the statement.Mit depends if it's a standard thing we missed - CC: @elithrar
MNo faster than a week.
KA random guess is that the D1 shim seems to do some ArrayBuffer conversions of it's own (https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/templates/d1-beta-facade.js#L112-L149)
IAre foreign keys actually supported? It accepts them in the schema, but it doesn't enforce them, at all.
IYeah, I know SQLite supports that, but they specifically state that the
PRAGMA foreign_keys = on; command is supported in the docs.
II saw your 
, @rozenmd, can I expect it to work at some point or not? Just to design the schema and Workers accordingly.
, @rozenmd, can I expect it to work at some point or not? Just to design the schema and Workers accordingly.Mlet me ask internally, I'm not sure
M
Mcan you rerun it with
fts5 instead of FTS5? looks like a bugIGitHub
The Experimental Backend doesn't allow using CURRENT_TIMESTAMP when running any type of query. It's supported perfectly when it's set as default value for a column.
Munixepoch is supported. Does that create table statement work outside of D1? Usually you can’t have functions like that.Mhttps://github.com/cloudflare/workerd/blob/bc3fc4cdd309dccc553e18240ef432a39f53d5eb/src/workerd/util/sqlite.c%2B%2B#L171 (the function is typo’ed on the allowlist)
GitHub
The JavaScript / Wasm runtime that powers Cloudflare Workers - workerd/sqlite.c++ at bc3fc4cdd309dccc553e18240ef432a39f53d5eb · cloudflare/workerd
MNot at my computer so asking, otherwise I’d test.
Mwhat are you using to insert btw?
a basic example seems to work:
a basic example seems to work:
Mdefault backend or experimental btw?