3 ms·
That certainly sounds appealing. Do you have any insights into if and when that might land on trunk?
by pstuart 3y ago
That certainly sounds appealing. Do you have any insights into if and when that might land on trunk?
- alberth 3y agoI'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.