3 ms·
> In the given design, am I understanding correctly that this means that a local commit could be seen as “committed” by the user but then later the server rejec
by ochiba 3y ago
> In the given design, am I understanding correctly that this means that a local commit could be seen as “committed” by the user but then later the server rejects it because of conflicts right?
> it does mean that you could lose data if the application author doesn’t handle that well in their local code or the application server yeah?
Yes, this is correct and the backend developer needs to make sure that conflicts are handled appropriately (I went into a bit more detail on this in my other comment in reply to langarus which you may have seen)
> So presumably the powersync service channel is for synchronization of Postgres -> local SQLite. Is that right?
Yes, this is correct.
> And the replication logic in powersync - is that essentially accomplishing horizontal sharding of the database for reads?
Assuming I understood this question correctly — yes, the PowerSync Service handles the complexities of dynamic partial replication of the database to different users. In our announcement blog post we wrote a bit more about the trade-offs and design considerations: https://www.powersync.com/blog/introducing-powersync-v1-0-postgres-sqlite-sync-layer https://www.powersync.com/blog/introducing-powersync-v1-0-po... (see section "A scalable dynamic partial replication system")
> Also, for the replication piece is the SQLite bit actually important or could you actually support arbitrary backends and SQLite is just convenient?
We do currently use a few different features of SQLite, but something that we are considering is making the client-side more database agnostic and potentially supporting more local database options (details TBD).
> Finally, do you have any support for lazy local hydration / eviction? Eg if I have a Google docs like application, is it synchronizing my entire account at all times or does it support pulling a document and evicting LRU documents when some local storage limit is exceeded?
It is possible to accomplish some of this kind of functionality using PowerSync's Sync Rules. It should be possible to design the Sync Rules such that flags are set (e.g. based on LRU) which would trigger certain rows to be synced/un-synced.
I think my co-founder (matharmin) may also want to weigh in with more detail on some of the answers. We are based in different timezones so we may reply with more information in a few hours.
- vlovich123 3y agoYeah I figured that given the static nature of declaring the sync rules ahead of time, dynamic control over what is synchronized may be tricky. You mention using a flag column, but wouldn’t that mean that you’re generating writes for reads to update that flag/timestamp? Or can you choose to have extra local columns that aren’t aren’t part of the replication data?
- ochiba 3y agoNote that dynamic control from the client-side over what is synced is currently supported to an extent via token parameters from the client, and this will potentially be expanded in the future. > You mention using a flag column, but wouldn’t that mean that you’re generating writes for reads to update that flag/timestamp? There may be other ways to solve this, but the solution that came to mind was: - Set a "last accessed at" timestamp on the client when the user opens a specific item. This would sync to Postgres. - Have a recurring task on the server-side that updates items in Postgres based on "last accessed at" and sets a flag that causes an item to be de-synced for that user once the elapsed time exceeds some threshold Persistent local-only columns are not currently supported. Local-only tables are currently supported.