Hacker News Reader

Comment by PreInternet01 | Hacker News Reader

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.

View on HN

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

>I haven't looked in detail, but I'm suspicious they are using the SQLite Session extension: 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).

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.

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.

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

> 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?

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.

Also makes no mention about schema changes.

Reply on news.ycombinator.com