Do you get clarity on the sub-query depth from `EXPLAIN QUERY PLAN` - ?
Do you get clarity on the sub-query depth from
EXPLAIN QUERY PLAN - ?
MThese limits aren't fixed in stone, but we need to be mindful about how and where we increase them. Understanding what practical applications are blocked on a lower limit -> helps me understand the trade-offs (vs. just blindly increasing to 1000)
JI’ll run that when I get a chance and report back
JPastebin
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
JThere are 30 rows, does that correspond 1:1 to expression depth?
IHow plausible is it to get one db per user ? currently limited to 10
I
Ior at least one table per user, but then there is the issue of db size limit
MI reckon it's plausible, but tell @elithrar what you're building
Mthere's a migration table we add to your db to track it: https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/d1/migrations/helpers.ts#L83
MThe example here is in TS: https://developers.cloudflare.com/d1/platform/client-api/#errors
- you can also use
e?.cause?.message
As part of our Client API, both static and prepared statements are supported. Best practice is to use prepared statements which are precompiled …
MNo, rows != depth. Depth correlates to sub-queries - if you have a sub-query that executes over every row, then it will correlate to depth. But that’s not a given.
II was thinking that every entity/user has their own "partition" or "account" and all the data and actions will be running against that partition, I reckon this is not SQL-like structure, was just curious if it was possible at all because of the good price for reads even at table sizes of 10M rows.
Mproblem is it's native, folks just don't know about it: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause
The cause data property of an Error instance indicates the specific original cause of the error.
Kfwiw it exists in TS's native types too
Knotably, it's a ES2022 thing (which is the target you should use for Workers)
Ljust switched to the experimental backend and am seeing huge performance gains. Love it, thanks for the hard work and I can't wait to see d1 get even better!
ASimple Q: is there a way to get the row(s) written to the DB when executing an INSERT with run()? (or a way to insert data and get the response without running a secondary query)
ANice, thank you - still two queries, but at least better than doing two sequentialy in the code 
AOh wow TIL also ty!
ty!
UAfaik it’s always been there 
MAll errors should (will) be thrown. An empty result set isn’t an error though, but
D1Result will have no rows
MMostly! March 2021 in SQLite.
UAh interesting that would’ve been after I started using it
MYou should handle the false case - let me take an action to iterate over the failure modes more explicitly
Wlooks like a wrangler bug, not seeing us exit with code 1: https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/d1/migrations/apply.tsx
can you file an issue on the wrangler repo?
can you file an issue on the wrangler repo?
HCould we use D1 with prisma?
J
HThis issue has opened more than 1 year But hope it soon
But hope it soonMThat issue was opened before D1 was even in open alpha, which was probably… a little premature 
(We’re close with the Prisma folks so expect something soon)
(We’re close with the Prisma folks so expect something soon)
LThere is 1 table and only 4 ip addresses are registered in this table.
Showing 65kb data.
What's the reason for that?
Showing 65kb data.
What's the reason for that?
LSize of the database with no tables created
DJust want to say AMAZING work on the new update D1 devs 
LYes you are right I created 1 table and created 3 headings to this table.
And I added 20 rows, the size did not change
And I added 20 rows, the size did not change
LI wonder after how many kb of data this size will start to increase
LNot without using Wrangler.
L