3 ms·

> sqlite cloud lmao

• mbreese 3y ago
  I get it, but seriously trying to wrap my head around it. But their example code took me a minute. And their demo code looks like: #include "sqlite3.h" #ifdef USE_LOCAL_DATABASE #define DATABASE "/var/databases/invoice.sqlite" #else #define DATABASE "sqlitecloud://username@password:localhost/invoice.sqlite" #endif int main (int argc, char **argv) { sqlite3 *db; rc = sqlite3_open(DATABASE, &db); } It took me a while to figure out they they are trying to replace the sqlite3.h file with a patched version that includes handling their own remote protocol. They (in theory) provide: > SQLite Cloud provides an open-source C library that is 100% source code compatible(1) with SQLite (based on our official SQLiteCloud C SDK). Why not ship a sqlite3_cloud.h file? You're already using a conditional macro anyway. I assume you could also swap this version in when compiling something like Python, but the friction for a company to use this is really high. Especially when SQLite is designed for a protocol-less, local, experience. I think the fly.io method of moving an application+sqlite3 database both to the same cloud node is probably the better choice. Or, it might be possible to do something with SQLite's virtual FS module to keep it all vanilla SQLite and still store the full database remotely.
  • iudqnolq 3y ago
    I'm not sure how they're implementing this. If they're replacing something low-level there's advantages to sharing the higher level SQLite code. No subtle incompatibilities depending on how you run it, less code duplication. Plus this makes it easy for a user to pick which way the data is stored in a config file or something.