wait then what does `db.dump()` do if not dumping the db content into an sqlite file?
wait then what does
db.dump()
MThat’s not available on the experimental backend, which will be the default in the near future.
MThe “original” alpha was, as alphas tend to be, a prototype: SQLite in Wasm. A lot has changed since then - some of that I wrote about in our recent blog: d1-database
MProd is
TL;DR: Yes.
workerd@a2fbc3dfe25"ALTER TABLE alterme RENAME COLUMN metadata TO somethingelse"TL;DR: Yes.
MLet me look into that. We may have a bug. @geelen
MThere’s likely an edge case with how our storage layer & authorizer interact with temp tables during a
DROP COLUMN
Ahow do I go about having my D1 id in
wrangler.tomlwrangler.tomlah got it. Awesome, good to know
AThank you!
WEverything in wrangler.toml is safe to have public 
IIs there a way to get all table names from D1 via a statement in the JS API?
II know of 
/tablesSELECT * FROM sqlite_master WHERE type = 'table' AND name NOT LIKE 'd1_%' AND name != '_cf_KV'That
_cf_KVThat one is shown even when doing
/tables
M/tablesi should probably add the filters
MSELECT name FROM sqlite_schema WHERE type='table' ORDER BY name;
MSELECT PRAGMA table_list, PRAGMA table_info(table_name)Also
index_list(table), index_info(index)Gotcha, thanks @rozenmd and @elithrar
MWith regard to
batchbatchbatch
MPer statement within a batch.
MDB.batch(statements)statements.lengthWonderful. Thank you for clarifying!
MAre there any sqlite compatible gui clients (like tableplus) that can connect to production D1 databases?
HMaybe? But for those kinds of Workloads, I would probably recommend #analytics-engine-beta, which is purposefully built for stuff like Analytics
MInteresting. Thanks!
MHow many writes per second are we talking?
MI second @HardAtWork - Analytics Engine is really good at these web analytics/clickevent use-cases. You can query directly out of it via GraphQL or SQL. We have folks writing thousands of events per sec.
UYeah that is per request not something shared between multiple requests
MThis means:
One client request to a Worker -> you can call
One client request to a Worker -> you can call
writeDataPoint up to 25 times (each write can include multiple metrics!) -> but you can have hundreds of thousands of client requests
OI got a weird bug - when adding d1 bindings to my wrangler.tml, I am loosing my es6 default exports (like the email function) cloudflare just doesn't see them anymore
I can even have an empty export default, cf won't see the worker as doing nothing (which it does if I remove d1 bindings)
Anyone with a clue what's ahappening ? How can I get wrangler to output my bundled js so that I can check what's going on ?
I can even have an empty export default, cf won't see the worker as doing nothing (which it does if I remove d1 bindings)
Anyone with a clue what's ahappening ? How can I get wrangler to output my bundled js so that I can check what's going on ?
MSo i noticed that d1 limits are that we can have max 10 databases per account. And I know thats going to change when d1 is released but my question is would it be smart to dedicate a d1 database for each saas tenant? Its not curcial or a requirment that tenants are on seperate databases.
ICan you share the source code of the Worker? To export the output bundle you can do
wrangler deploy --dry-run --outdir ./distOI'll try tonight. While waiting I set up neon. But mainly it's a vanilla setup, es6 style, with fetch and email as part of the default export. And d1 bindings in the wrangler.toml
Varchitecturally D1 is a single writer multiple reader replicas type of situation? are there any guarantees for the reader replicas or they are eventually consistent?
HCurrently, it is a single-reader/single-writer setup, though I believe the plan is for eventually consistent read-replicas.
VIs it a good idea to push immutable/rarely edited but heavily read data to KV to act as a cache in front of D1? I guess definitely now but even later on with read replicas it should be cheaper to get a key from KV than to run a query on D1
