Is there a way to intentionally throw a proper D1 error that has an `error.cause` attribute?
Is there a way to intentionally throw a proper D1 error that has an
error.cause
MCatch and re-throw with
error.cause.messageAs part of our Client API, both static and prepared statements are supported. Best practice is to use prepared statements which are precompiled …
MThat's what I ended up doing 
MBut what I was really interested in was if there was an easy way to trigger an error. Trying to test that the try/catch is working properly but didn't want to get hacky with the actual queries.
MNever mind, I see an example in the docs! Thanks for the direction!
HIs there a way to
run()
MLike
.exec()- what are you trying to do? You can just… ignore the result.
await db.batch(statements)
Msmh i can’t post a dang drizzle discord invite link
Mwell anyways there’s a drizzle discord
MexZajY9H
HIsn’t that the point with
run()run()first()all()So like, it’s not that you can’t just ignore the results
HJust that it is more efficient to not have them sent in the first place
MCan you expand on what you’re trying to do - why don’t the results matter? We don’t have an API to modify a batch to behave like
run()As an example, take the code in the docs for
batch(): In the case of an UPDATE, you probably don't care what it returns, just that the entire thing completes, so returning anything more than statistics on the statement execution isn't needed. And this isn't for a specific use case, this was more just out of curiosity on why batch() works the way it works.
MPotentially, but we can’t commit/confirm the use of any specific extension. A lot of them are both very new and extremely untested (wrt security and stability).
MKV. @mhart on our team built a vector store over KV. He’s committed to publishing an example!
MKeep in mind D1 is in alpha. These limits will increase!
