Problem: need to have a way of selecting the lower-level store. Right now we have just two (native SQLite btree, and LMDB) and the way we select in this early design is by replacing btree.c to be one or the other. Even this implies that there is a common API with the higher layers.
What has been agreed after lots of discussion is that at minimum LumoSQL needs:
-
a backend API that includes a selector, so that (for example) a new table can be created in the users choice of backend. In the trivial case, this would be a configuration parameter that specified the backend to be used for the next session. In the simplest useful case, this would be for reading data from one backend and writing it out to another for backup or other batch-type purposes.
-
The ability to have multiple backends open for concurrent and async access. In the first version this still needs to be not very visible to any higher layer, which involves defining what the term "selector" means.
-
An API for more than key-value stores, however, to start with, one that handles only local key-value stores will be sufficient. This suggests that perhaps the architecture may extend to have a backend type selector, where all local key-value stores are considered to be very similar and that other kinds of backend have somewhat different APIs.
Problem: need to have a way of selecting the lower-level store. Right now we have just two (native SQLite btree, and LMDB) and the way we select in this early design is by replacing btree.c to be one or the other. Even this implies that there is a common API with the higher layers.
What has been agreed after lots of discussion is that at minimum LumoSQL needs:
a backend API that includes a selector, so that (for example) a new table can be created in the users choice of backend. In the trivial case, this would be a configuration parameter that specified the backend to be used for the next session. In the simplest useful case, this would be for reading data from one backend and writing it out to another for backup or other batch-type purposes.
The ability to have multiple backends open for concurrent and async access. In the first version this still needs to be not very visible to any higher layer, which involves defining what the term "selector" means.
An API for more than key-value stores, however, to start with, one that handles only local key-value stores will be sufficient. This suggests that perhaps the architecture may extend to have a backend type selector, where all local key-value stores are considered to be very similar and that other kinds of backend have somewhat different APIs.