4 ms·
Yeah 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 usin
by vlovich123 3y ago
Yeah 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.