π Hi! The current implementation of D1 is limited by the memory limit of Workers/Durable Objects. T

If your use case requires a larger database, please reach out!insert into user_agent (value) values ('test2') on conflict(value) do nothing returning id the first time i get the id and then for every new request the last row id is bumped and not returned, is this a d1 or sqlite thing?test returns 1test returns nothing (insertion doesn't happen)test1 returns 3insert into user_agent (value) values ('test2') on conflict(value) do update set value = excluded.value returning id works, but it feels wrong...

--persist to keep the data between runsIf the first statement after BEGIN DEFERRED is a write statement, then a write transaction is started.). But I don't see any examples in the docs that include BEGIN..., so I'm assuming that's abstracted away?Our implementation guarantees that each statement in the list will execute and commit, sequentially, non-concurrently. Batched statements are SQL transactions. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence.implementation was primarily looking at batches, which are definitely a cf wrapper which could influence thingsIf your use case requires a larger database, please reach out!insert into user_agent (value) values ('test2') on conflict(value) do nothing returning idtesttesttest13insert into user_agent (value) values ('test2') on conflict(value) do update set value = excluded.value returning id--persistIf the first statement after BEGIN DEFERRED is a write statement, then a write transaction is started.BEGIN...Our implementation guarantees that each statement in the list will execute and commit, sequentially, non-concurrently. Batched statements are SQL transactions. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence.implementationbatches