SQLite offline sync for Android quick start(github.com)
github.com
SQLite offline sync for Android quick start
https://github.com/sqliteai/sqlite-sync/tree/main/examples/android-integration
19 comments
Does this have any relation to: https://github.com/vlcn-io/cr-sqlite ?
Some of the API naming is similar (db_version, site_id, seq, commit_alter, etc), although the project source is very different (C rather than Rust, different feature set).
crsqlite is no longer maintained so I might be interested in migrating.
Some of the API naming is similar (db_version, site_id, seq, commit_alter, etc), although the project source is very different (C rather than Rust, different feature set).
crsqlite is no longer maintained so I might be interested in migrating.
API naming looks similar, probably because we are based on the same scientific paper: https://munin.uit.no/bitstream/handle/10037/24430/article.pd...
Very cool, I'm working on something similar!
Naturally I have some questions:
1. I don't see any examples for foreign key constraints (ON DELETE and ON UPDATE) or UNIQUE constraints. Are constraints still supported? 2. How is row-level privacy implemented? Are "forbidden" rows not synced by the server logic, or are they encrypted?
Naturally I have some questions:
1. I don't see any examples for foreign key constraints (ON DELETE and ON UPDATE) or UNIQUE constraints. Are constraints still supported? 2. How is row-level privacy implemented? Are "forbidden" rows not synced by the server logic, or are they encrypted?
1. Good point, we are going to publish more details about constraints in the repo within a few days
2. We have implemented row-level security, so you are free to easily implement any privacy role you want: https://docs.sqlitecloud.io/docs/rls. The "forbidden" rows are not synced
About encryption: all communications are over TLS.
About encryption: all communications are over TLS.
Thanks for the clarification.
Looking forward to see your solutions to the constraint problems.
Looks nice but not open source
It is open-source: https://github.com/sqliteai/sqlite-sync
It's "source available", but for commercial use : "For production or managed service use, please contact SQLite Cloud, Inc for a commercial license."
So not open source.
So not open source.
Yes, you are formally right, it is source available.
"technically correct is the best kind of correct" ;)
Elastic license, so many people refer to this as source available rather than open source
https://litesync.io/ seems very decent
"The full version of LiteSync is released under a Commercial License."
My bad! Thanks for pointing it out.
We chose to adopt the Elastic License 2 primarily because of the significant investment we've made in developing this technology, including a robust cross-platform network layer that enables users to implement offline-first functionality with just two lines of code. This license also helps protect our work from being forked and commercially exploited by larger tech companies.
̶L̶o̶o̶k̶s̶ ̶l̶i̶k̶e̶ ̶y̶o̶u̶’̶r̶e̶ ̶i̶n̶f̶r̶i̶n̶g̶i̶n̶g̶ ̶o̶n̶ ̶t̶h̶e̶ ̶S̶Q̶L̶i̶t̶e̶ ̶a̶u̶t̶h̶o̶r̶’̶s̶ ̶t̶r̶a̶d̶e̶m̶a̶r̶k̶.̶
Edit: Thanks for clarifying that. It'd be great if you can add it to your README, because the name looks very suspicious at first glance. If you have the rights to use it, explicitly mention it.
Edit: Thanks for clarifying that. It'd be great if you can add it to your README, because the name looks very suspicious at first glance. If you have the rights to use it, explicitly mention it.
This is not true. We are also backed by Dr. Richard Hipp, the creator of SQLite, and we have all the rights to use the SQLite name in our products.
Looks really cool! Congrats on the launch
It would be cool if the server-side sync API was also documented and versioned, which would allow the possibility of independent compatible self-hostable backend implementations to offset the vendor-lock-in concern.