You should update to the latest wrangler first, especially if you’re not on v3+
You should update to the latest wrangler first, especially if you’re not on v3+
MIt won’t be the queries. Yours are trivial. Likely a bug on our side. The new storage subsystem is still, well, new 
AYes, this is how I've done it
Ayour way is definitely cleaner than mine XD
HI think it is because
wranglertoml. They are adding a system to parse JSON into an object that wranglertoml spec, but there may be some points that don't just workHAnd which config format is the best is an extremely hot topic.
HWell, 
workers-rs), plus
wranglertoml. And you can still run Workers entirely without writing JS(see #workers-rs), plus workerd
MI'm already on 3.0.1
MYes - 100MB is the limit for now. We aren’t increasing database limits yet. Hold tight.
MIt's definitely not an experimental database (I just got online and checked:
e68dccd4-7bf7-4860-ba18-17978966ec10 is on the older alpha backend)
MLooked at the wrong ID, ha. I see ~11 storage timeouts in the last 24 hours on that DB. This is related to a larger issue we're investigating.
MAhh okay
VHey there! It's feedback time! 
We would love to hear from you. What features do you wish D1 had? 
And what's your biggest challenge or frustration when using D1?
We would love to hear from you. What features do you wish D1 had? And what's your biggest challenge or frustration when using D1?
《My wish would be for more defined error messages. When executing a sql script. Often the error message is 'D1 Error' with no supporting information.
《Yeah, this is for wrangler sorry. Maybe wrong thread
UThat is valid feedback here also as its related to D1 still.
MWe're going to lift the errors out of
error.cause into the top-level errorHard to really schedule. Outside of an alpha it'd be a compatibility date, but we have to then carry that forever, and I'm going to lean on the "alpha" part of "alpha" here. Likely within the week. We're going to keep
error.cause around until open beta, then trim that up.MHi, is there any d1 orm except drizzle which support joins?
MI asked this because of this problem https://github.com/cloudflare/workers-sdk/issues/3160
Tried kysely. It works
Tried kysely. It works
GitHub
Which Cloudflare product(s) does this pertain to? D1 What version of Wrangler are you using? 2.19.0 What operating system are you using? macOS Describe the Bug As per issue #555 we can see, that d1...
HAnyone remember whether D1 Auto-Vacuums, or whether we should run them ourselves periodically?
MRight now: neither. We need to implement auto-vacuum. You can't run it yourself. But we don't include the free list in the reported/restricted size. More of an "us" problem right now.
HAre there any other things you recommend doing to maximize performance? I’ve read about a couple of Pragmas you can set, but I’m not sure what applies/works with D1
HOr, more like, is there something about Best Practices?
MIndexes! One good index goes a LONG way.
MThere will be docs about all of this — just takes time to write.
Sis there a way to specify the
migrations_dir with the cli? I'm working on a pages project and it doesn't have a wrangler.tomlnpx wrangler d1 migrations apply <DB> --migrations-dir=<dir> but it's not working.
MNot currently, no. Pages does not support a config file.
SIs that a planned feature? Any suggestions on what can I do to manage migrations meanwhile?
MIt is planned. There is not currently a workaround. cc @nevika
MIs there an easy way to get a prepared d1 statement as text (with the bindings applied) ?
MNot at the moment, no: not something we yet expose.
MGitHub
Blocked until cloudflare/workers-sdk#3416 is merged.
As of wrangler 3.1.1 the top-level Error property will now include the detailed error message.
Although Error.cause is standardized & in th...
As of wrangler 3.1.1 the top-level Error property will now include the detailed error message.
Although Error.cause is standardized & in th...
II just changed my code to show 
error.cause 
MWe’ll intend to keep that as is for a bit, but it’s an overdue change. Doesn’t matter that 
.cause is standard, unfortunately IOh yeah, don't worry... I was one of the people not using it until you told me
MNo, the docs just got ahead of the release. Still 8.
LHello, I would like to establish a connection between workers and mongodb, is there a tutorial on this?
MIs there any work around to, locally, somehow inspect what the end query result is with the bindings applied? It's super hard to debug queries if they're working directly in the DB but failing when D1 is trying to apply a bind. Any way to replicate what's under the hood in a custom debug function?
MI see what's up now that I'm looking at the facade. The statement and bindings are sent to sqlite so there is no local interpolation. Anyway way to log d1 queries at the database level?
MDrizzle has a way of letting you see the actual query it runs, I don't think we have that as part of D1 yet
MDoes Drizzle even work properly with D1? I was seeing posts around people having to jump through hoops to get it to work.
MIt works, it just has column name collisions when joining tables with the same column names + not using aliases
MOk, thanks @rozenmd , will take a look. Feels like overkill to debug a query with an ORM, haha.
MUnfortunately, it's not that simple. Dumping the statement and bindings gives you the component pieces but does not allow you to introspect how they're being married together to form a complete query.
In this instance (just solved it), an integer value was being bound to the query as a string. I had to explicitly cast that particular parameter value with
In this instance (just solved it), an integer value was being bound to the query as a string. I had to explicitly cast that particular parameter value with
parseInt