Is there a way to get all table names from D1 via a statement in the JS API?
Is there a way to get all table names from D1 via a statement in the JS API?
II know of 
/tables in the console, but does that work in the JS API? ISELECT * FROM sqlite_master WHERE type = 'table' AND name NOT LIKE 'd1_%' AND name != '_cf_KV'IThat 
_cf_KV table isn't really usable, it doesn't let you see it IThat one is shown even when doing
/tables, though 
M/tables literally just runs that query against the execute endpointMi should probably add the filters
MSELECT name FROM sqlite_schema WHERE type='table' ORDER BY name; is what it runs
MSELECT PRAGMA table_list, PRAGMA table_info(table_name)MAlso
index_list(table), index_info(index)IGotcha, thanks @rozenmd and @elithrar
MWith regard to
batch operations, is the Maximum SQL statement length of 100,000 (100kb) applied to the entire batch or is that applied to the individual statements within the batch?
MPer statement within a batch.
MDB.batch(statements) where statements.length is 400 = 400 statements.MWonderful. 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
UD1 will be way cheaper than KV is (assuming small values at least). And I would use the cache api as a cache
VIt will be cheaper? Damn.. how? If it will have the same eventual consistency characteristict I don't see why would they make it cheaper
UWhile in public Alpha, D1 is currently free to use on all Workers plans. Refer to the our recent announcement) for more information.
VA lot more computes goes into serving a D1 request than just a KV get, or thats what it feels like anyways
UStorage is more expensive but reads/writes are cheaper but you have to use small values
Vat 2 MB / read they are the same price
V2MB is a lot.. 
U1MB is the max size of a value in D1
Uand do note that writes are significantly more expensive than that of reads... 1 million writes of 1MB is $1000
U5KB would cost the same as far as writes go but generally you probably wont go over 5KB that often for a normal DB usage 
Vso for large or somewhat large writes/reads KV is cheaper
