YAhh missed that, thanks
KThe message will start with D1_ and that’s about it
K
LHello, why can't I load the table page?
Is the data stored in d1 too large? There are no such issues in another smaller database.
Is the data stored in d1 too large? There are no such issues in another smaller database.
THope they will create a native api to dump/load the D1 db to/from local machine or R2 soon. Sometimes we need databases dumped from staging environment for some database debug since D1 query debugging (especially when migrating database) is very limited. D1 DB is nice to work with, but dealing with altering table and migration is not a pleasant experience. Thankfully they released time traveling feature so I can go back to a point of time if my migration's gone wrong
T
Lmy database id is 0c148108-729d-4796-be8b-25a27dead6b8 
ZThis is "legacy" unfortunately, meaning it only works on alpha databases (were in the beta now). Thanks for your help though.
ZBrilliant, thank you
YI'm trying out D1 and like it but am wondering if I should just use it for all my data needs or if KV still has an advantage sometimes.
UKV is not in beta so if you are doing something production KV should be used over D1.
D1 also does not replicate data yet, KV does.
KV can store larger values.
KV can handle way more load.
D1 also does not replicate data yet, KV does.
KV can store larger values.
KV can handle way more load.
MKV has replication lag, which might trip you up
YThanks! So I'm building a sort of keynote / pitch deck viewer. My idea was to use D1 to store which users have access to which pitch decks. And then I would store the actual pitch deck data (markdown) in a KV. Does that sound reasonable?
YOr would it actually be easier to simply store everything in KV?
YLike...
decks-{userId} as key, and the value would just be a list of deck ids?UJust depends what you want to do 
If you want my personal preference I would store authorization data in durable objects and store the markdown in R2.
If you want my personal preference I would store authorization data in durable objects and store the markdown in R2.
UTheres a million way to solve the same problem so its mostly personal preference in the end
YR2 even if the markdown ist going to be edited a lot, by multiple users?
BHello,
Is there any chance someone here help with the D1 port to Prisma ORM? There is a issue with a lot of interactions and a start code with this integration. Take a look https://github.com/prisma/prisma/issues/13310#issuecomment-1880028618
Thanks
Is there any chance someone here help with the D1 port to Prisma ORM? There is a issue with a lot of interactions and a start code with this integration. Take a look https://github.com/prisma/prisma/issues/13310#issuecomment-1880028618
Thanks
GitHub
Cloudflare have just announced their first relational DB D1 which is based on SQLite. https://blog.cloudflare.com/introducing-d1/ Would be awesome if Prisma could support it one day..
UYes
UNo I would use R2 because its cheaper. KV is way too expensive of a service imo
YYeah my bad. Saw that in the docs a few minutes after I sent it...
ZNo problem, still thanks for looking
Gwhy am i getting this error??
i thought booleans get converted to D1 integers 1 or 0?
"Error: D1_TYPE_ERROR: Type 'boolean' not supported for value 'true'"i thought booleans get converted to D1 integers 1 or 0?
KDocumentation seems to imply it should, but it isn't.
Kresults.error isn't really a thingKyou need to
try/catch the .all()What is the issue you're having with the code?
KWhich part in particular isn't working
KWhat part of your retry logic doesn't work though, which line do you get to before it fails?
KI meant the retry logic, I can't help with the D1 error itself.
KshouldRetry checking error.name is wrong because error.name will just be Error
KYes
AI have found a bug with D1 table web view,
the column data for
The output from the
the column data for
namestock_code in the table web view.The output from the
select * query is correct
