The way backends currently work doesn't make a lot of sense, and the in-memory database doesn't bootstrap properly.
I think it should probably work something like this. Instead of an in-memory and a sqlite backend, there should be one sqlite backend. Sqlite already has an in-memory option, so this distinction isn't necessary. What is important -- and isn't clear or obvious right now -- is where the transactor runs. There should be two options for this:
a. The transactor runs as a separate process, maintains a sqlite db on-disk, and serves reads. (This can be called the tx backend or something.)
b. The client runs a transactor in-process, limiting the use of the db to that process even if it's an on-disk database. This would could be called the file backend, since sqlite is an implementation detail -- what's important is that data is stored in a file and can only be used by a single process at a time.
The way backends currently work doesn't make a lot of sense, and the in-memory database doesn't bootstrap properly.
I think it should probably work something like this. Instead of an in-memory and a sqlite backend, there should be one sqlite backend. Sqlite already has an in-memory option, so this distinction isn't necessary. What is important -- and isn't clear or obvious right now -- is where the transactor runs. There should be two options for this:
a. The transactor runs as a separate process, maintains a sqlite db on-disk, and serves reads. (This can be called the
txbackend or something.)b. The client runs a transactor in-process, limiting the use of the db to that process even if it's an on-disk database. This would could be called the
filebackend, since sqlite is an implementation detail -- what's important is that data is stored in a file and can only be used by a single process at a time.