should i store json as a blob or text?
should i store json as a blob or text?
MTEXT
MNew docs & updates:
- Metrics & analytics (now in the dash & via our GraphQL API): https://developers.cloudflare.com/d1/platform/metrics-analytics/
- Generated columns (very powerful way to extract + index JSON, amongst other things): https://developers.cloudflare.com/d1/learning/generated-columns/
- Deprecating
Error.cause: https://developers.cloudflare.com/d1/changelog/#deprecating-errorcause
MNo ETA at the moment. We are focused on metrics, Time Travel (point in time recovery), and stability.
MCurious: what happened? 
MMatt Silverlock 🐀 (@elithrar)
Twitter
•
If you've used @Cloudflare D1, you may not realize that you can create generated (aka: virtual) columns based on properties within raw JSON objects
- indexes over those properties to (dramatically) speed up access to often-queried properties.
6/27/23, 6:02 PM
MI think triggers are the right approach here and/or a formal audit logging feature.
MAt some point we want to expose Workers-based functions. We won’t be exposing raw SQLite APIs.
MThat’s the rough plan. Won’t be soon — lots of more foundational things to solve first
IThat would be really cool Understand the next message, but very cool.
Understand the next message, but very cool.
OI might be really stupid here, however when using a D1 database locally it works fine, however when I push the same code to running on workers, it produces this error:
If more info is needed please lmk, I'm likely missing something really simple but thats why I'm here
If more info is needed please lmk, I'm likely missing something really simple but thats why I'm here
KDo you have an example of the query you're running into issues with?
Oi'll get it one moment
Owelp nevermind, it was a PRAGMA for
user_version and I just read the docs on PRAGMA so I'll come up with a workaround - ty
MCurious: what are you trying to do with storing data in user_version?
IIt's probably a known issue, but in the metrics tab these don't show anything, in other graphs they do.
Mnot implemented yet 
IOk, "known" issue then 
no problem ahah
no problem ahah
AOut of curiosity, what are your thoughts on the stability of the experimental backend vs the old backend for D1?
I have a few projects that are using the old D1 backend, is it worth switching now or should we wait for the beta?
I have a few projects that are using the old D1 backend, is it worth switching now or should we wait for the beta?
UI mean both are inheritly unstable given its alpha
UThe new backend should be faster but doesnt have backups at the current moment afaik
AYup, asking with the assumption of the alpha tag haha. I more asked because when the new backend came out, I noticed that there were enough obvious errors that switching didn't make sense. Wondering if the situation has improved now to the point that a general happy path (simple query + insert statements with low load) isn't expected to encounter errors.
CThe execution times are noticeably better and there haven't really been many major issues I've seen in this channel. Do keep in mind that the new backend doesn't have backups yet
AGot it, that's good to know . I suppose once backups are available it makes sense to switch then
. I suppose once backups are available it makes sense to switch thenCKeep in mind it isn't going to be a sql dumb zip but Time Travel.
https://blog.cloudflare.com/d1-turning-it-up-to-11/ search for Time Travel header
https://blog.cloudflare.com/d1-turning-it-up-to-11/ search for Time Travel header
Pi have a decent oltp db in mysql, about 150gb, that i would love to get into d1 so the performance is going to be a real issue
Pi have workers serving 500 req/sec out of kv at the moment but im really interested in having the backend db in d1, pushing aggregated data into kv
Mfwiw #analytics-engine-beta is ridiculously good for high rps analytics data, we're using it to power the stats in the dashboard
MHello, I planned to use d1 on a future product. I'm asking if there will be some breaking change from the alpha release to the production ready d1 ?
UIt is possible
UMNot Final / Initial Release / MVP but... we're close. Hoping to land this within the next 2 weeks.
- Our v1.0 will replace the DB in place.
- In future, we'll default to a
--fork/--cloneapproach and make overwriting (even more) explicit. - We'll explore adding helper flags - e.g.
--minutes-ago=15mor similar to avoid you having to deal with Unix timestamps.
IIdeally it'd be great to have either a duplicate or a way to lock a version too keep it "forever".
MRight, that'd be
--clone/--fork - just copy it to a fresh DB and do what you want.
--clone=new-name
IThe "lock" action is very intuitive given it's common for many things, but this would be great regardless.
MCan you expand on what "lock" means - e.g. no longer accepting writes? At all?
ILet me find you an example.
MOr do you want to say "keep this version forever" (which is... cloning that bookmark to a DB you can keep)
M(Then you end up with several things to manage - you have "regular" databases and then some set of "persistent locked copies" that exist at a meta layer, and charge you for storage)
