An important goal for the C client library is that porting an application from SQLite to dqlite should be convenient, involving as few invasive changes as possible. It's not possible to re-use functions like sqlite3_prepare_v2 or sqlite3_exec because the corresponding operation in dqlite needs to do novel things like connect to a leader and speak the wire protocol, but in principle it seems like we should be able to re-use many parts of the sqlite3 API that don't don't do any I/O. For example, it would be great if packing values into a tuple of statement parameters or unpacking a sequence of rows could work with no code changes when doing this migration.
The second-best interface would have dqlite* functions for all these purposes whose signatures are completely analogous to the sqlite3* function, so that most of migrating a codebase is just replacing the first part of the name of various functions.
A couple of issues:
Key structs like sqlite3_stmt are opaque, so we can't just embed them in our own dqlite_stmt.
Re-using any sqlite3 function commits clients to linking in libsqlite3. For the high-level client that's not an issue because libdqlite already links against libsqlite3, but we should think about what a potential "thin client" would have to do.
An important goal for the C client library is that porting an application from SQLite to dqlite should be convenient, involving as few invasive changes as possible. It's not possible to re-use functions like sqlite3_prepare_v2 or sqlite3_exec because the corresponding operation in dqlite needs to do novel things like connect to a leader and speak the wire protocol, but in principle it seems like we should be able to re-use many parts of the sqlite3 API that don't don't do any I/O. For example, it would be great if packing values into a tuple of statement parameters or unpacking a sequence of rows could work with no code changes when doing this migration.
The second-best interface would have dqlite* functions for all these purposes whose signatures are completely analogous to the sqlite3* function, so that most of migrating a codebase is just replacing the first part of the name of various functions.
A couple of issues:
sqlite3_stmt
are opaque, so we can't just embed them in our owndqlite_stmt
.