Option to run a few queries sequentially

[davidmartos96]

Currently the DelegatedDatabase has the notion of isSequential in order to support parallel queries and transactions.
On ElectricSQL they recently introduced the option to disable the foreign key checks when replicating from remote, as it has better performance on web.
In order to do that it's necessary to do that in a safe manner, they do the following in a mutex. This is because foreign_keys cannot be called during a transaction.

PRAGMA foreign_keys = OFF;
SQLite transaction block {
	...
}
PRAGMA foreign_keys = ON;

Given that Drift can already work with sequential databases we were wondering if it would be feasible to add a function that runs a callback inside the same synchronized Lock. Something like runSequentially or runExclusively.

Context:
electric-sql/electric#1281
https://github.com/electric-sql/electric/blob/64a01949376536492fbc72fe6bf0d8539a3552b0/clients/typescript/src/util/transactions.ts#L23

[simolus3]

I think you'd still have the problem with sequential databases because they only serialize database access at a fairly low layer.

So if you do something like this Dart:

await customStatement('pragma foreign_keys = OFF;');
await transaction(() async {
  // ...
});
await customStatement('pragma foreign_keys = ON;');

If another async context is accessing the database and does its own thing, queries from there could be interleaved between the customStatement and transaction block, even with isSequential: true.

I agree that having a block that reliably locks the database is a good addition. It should ideally be implemented at a QueryExecutor level though (doing it in the database class is not reliable since this also needs to work across isolates, so there could be multiple database classes talking to the same logical database). Doing that there is a breaking change though...

[davidmartos96]

@simolus3 I was thinking at the BaseExecutor level, which already manages its own lock. Is that the database low level you were referring to or the QueryExecutor level?

If the additional method is added to the QueryExecutor and to the DatabaseConnectionUser classes, what is the breaking change? Is it because subclasses need to implement it?

[simolus3]

No you're right! I've misremembered things and thought QueryExecutor was a public and stable interface. It's explicitly marked as internal in the documentation though, so I feel comfortable adding a beginExclusive method there and implementing it in the BaseExecutor (well, and in the remote isolate implementation and so on). I haven't completed this yet, but it doesn't look like a breaking change outside of minor concerns for web workers (beginExclusive will only work with newer workers due to a backwards-compatible change to the RPC protocol, that is not a problem though).