4 ms·

I'm not entirely opposed to a commercial product, but the list of documented limitations does not make me reach for my wallet just yet: 1. Avoid using function

I'm not entirely opposed to a commercial product, but the list of documented limitations does not make me reach for my wallet just yet: 1. Avoid using functions that return different values each time they are called, like random() and date('now') 2. AUTOINCREMENT keyword is not supported 3. We must use just a single connection to each database file. Do not let many apps access the same database file. Each instance must use its own db file, and then they will be replicated and synchronized using LiteSync There are definitely obvious technical reasons for these, but it may make using the product for existing apps pretty much impossible. Also worrisome is the lack, at least anywhere in the examples, of authentication parameters on the (proprietary, I guess?) TCP replication protocol, and no mention of over-the-wire encryption.

jitl 4y ago
RANDOM and NOW you can easily do in application space. AUTOINCREMENT you can replace in application space with nanoid, or similar semi-random ordered ID. These practices are standard if you’re creating any data offline on clients or syncing two ways.
LamaOfRuin 4y ago
Also no mention of how it handles conflicting transactions from separate nodes.
samwillis 4y ago
As LiteSync used eventual consistency AUTOINCREMENT isn't possible. You would have collisions when a node come back on after what they are calling "Airplane Mode". I suspect the issue with random() and date('now') similarly are they it will replay transactions on other nodes, and these would return different values. Obviously they could design the system to save the values for returning when replaying a transaction if they decided it was necessary. I haven't looked in detail, but I'm suspicious they are using the SQLite Session extension: https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html
- sebastien_b 4y ago
  >I haven't looked in detail, but I'm suspicious they are using the SQLite Session extension: https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html Having used the Session extension extensively, from reading the info this would also be my conclusion (makes no use if it, which to me makes little sense).
- paulclinger 4y ago
  I don't think they are using the session extension, as this project provides its own binary encoding, which wouldn't be needed if the session extension is used. It wouldn't affect random/date either, as the session extension doesn't replay transactions, but captures applied changes as changesets (so it would capture the results of random/date), which can then be applied to other nodes.
sebastien_b 4y ago
Also makes no mention about schema changes.
avtar 4y ago
> 3. We must use just a single connection to each database file. Do not let many apps access the same database file. Each instance must use its own db file Isn't this a sqlite limitation?
- sebastien_b 4y ago
  There are file locking mechanisms you can opt into (compile time options) to have multi-process access to the same database file - it does require either some coordination and/or more error handling, especially when writing to the database.

jitl 4y ago

RANDOM and NOW you can easily do in application space. AUTOINCREMENT you can replace in application space with nanoid, or similar semi-random ordered ID. These practices are standard if you’re creating any data offline on clients or syncing two ways.

LamaOfRuin 4y ago

Also no mention of how it handles conflicting transactions from separate nodes.

samwillis 4y ago

As LiteSync used eventual consistency AUTOINCREMENT isn't possible. You would have collisions when a node come back on after what they are calling "Airplane Mode". I suspect the issue with random() and date('now') similarly are they it will replay transactions on other nodes, and these would return different values. Obviously they could design the system to save the values for returning when replaying a transaction if they decided it was necessary. I haven't looked in detail, but I'm suspicious they are using the SQLite Session extension: https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html

sebastien_b 4y ago
>I haven't looked in detail, but I'm suspicious they are using the SQLite Session extension: https://www.sqlite.org/sessionintro.html https://www.sqlite.org/sessionintro.html Having used the Session extension extensively, from reading the info this would also be my conclusion (makes no use if it, which to me makes little sense).
paulclinger 4y ago
I don't think they are using the session extension, as this project provides its own binary encoding, which wouldn't be needed if the session extension is used. It wouldn't affect random/date either, as the session extension doesn't replay transactions, but captures applied changes as changesets (so it would capture the results of random/date), which can then be applied to other nodes.

sebastien_b 4y ago

Also makes no mention about schema changes.

avtar 4y ago

> 3. We must use just a single connection to each database file. Do not let many apps access the same database file. Each instance must use its own db file Isn't this a sqlite limitation?

sebastien_b 4y ago
There are file locking mechanisms you can opt into (compile time options) to have multi-process access to the same database file - it does require either some coordination and/or more error handling, especially when writing to the database.