4 ms·
I'm not sure it ever will. The primary use case of this branch is to make SQLite into a more "client/server" like architecture, which deviates from the predomi
by alberth 3y ago
I'm not sure it ever will.
The primary use case of this branch is to make SQLite into a more "client/server" like architecture, which deviates from the predominate target use of SQLite (embedded).
Though I too would love a client/server version of SQLite.
- pstuart 3y agoI'd put it more at "multi user" rather than client/server. I'm confident that that goal will never be acceptable reasoning for any changes or improvements to the code.
- alberth 3y agoI’d still say “client/server” because: a. SQLite, by default, doesn’t allow multiple writers. b. There’s also real challenges to writing to a non-local (network) filesystems https://www.sqlite.org/useovernet.html https://www.sqlite.org/useovernet.html
- pstuart 3y agoFor sport I'll counter with: a. SQLite, by default, does allow multiple writers to connect, but only one can write at a time. b. NFS was never suggested to be used -- embedding it in an app that exposes a network api works fine. c. The behavior being discussed (multiple concurrent writers) already kind of exists (multiple writers) and this would just make them more performant.