Wire protocol limitations as a backend for the C client about dqlite HOT 5 CLOSED

Oh, it's because the QUERY codepath doesn't do a VfsPoll to propagate any changes to the database.

Yeah, it's "read only" and doesn't go through raft.

from dqlite.

Specifically, running (in pseudocode):

stmt = PREPARE("CREATE TABLE foo (n INT)");
QUERY(stmt);

works fine, but afterward attempting to prepare a statement like SELECT * FROM foo will fail with "no such table". I haven't figured out why this is -- sqlite3_step does get called on the CREATE statement and returns SQLITE_DONE, which should also be what happens when running an EXEC request.

from dqlite.

Oh, it's because the QUERY codepath doesn't do a VfsPoll to propagate any changes to the database.

from dqlite.

I think it should be possible to implement the new request (pre-bikeshed name: GENEXEC) to reuse the existing code in leaderExecV2 and query__batch -- experimenting with that now.

from dqlite.

One other option that might be a bit easier both for the client and for the server is to modify the response the PREPARE request adding a flag indicating if the statement is read-only or not. That flag can be stored in the dqlite_stmt object along with the statement ID, and subsequent calls to dqlite_step will invoke the correct API (either QUERY or EXEC) based on that flag.

The sqlite3_stmt_readonly SQLite function can be used by the server when processing the PREPARE request to determine the value of the flag to include in the response.

YMMV

from dqlite.