Replies: 1 comment 1 reply
-
All the merge logic is handled for you. The only thing you need to ensure
is that when you record having seen changes up to a given database version
from a peer, you request the next set of changes from that peer starting at
(or before) that same version.
Let me know if this helps:
https://vlcn.io/networking/whole-crr-sync
…On Fri, Apr 14, 2023 at 3:58 PM Jerome Gravel-Niquet < ***@***.***> wrote:
Here I'm wondering if the LWW example means I should set at least 1
column as a LWW to determine when to update a row?
Or is this handled by crsql? I assume this means changes should only be
applied in order.
I'm building the next version of a project that will send "changes" that
can be received in any order by peers. Does that mean I can't apply updates
unless they're exactly +1 of the last known version from a peer?
—
Reply to this email directly, view it on GitHub
<#187>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHWK22C2GEDGDQN3OXQ7S3XBGT77ANCNFSM6AAAAAAW63BQMA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
Answer selected by
tantaman
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Here I'm wondering if the
LWW
example means I should set at least 1 column as aLWW
to determine when to update a row?Or is this handled by crsql? I assume this means changes should only be applied in order.
I'm building the next version of a project that will send "changes" that can be received in any order by peers. Does that mean I can't apply updates unless they're exactly +1 of the last known version from a peer?
Beta Was this translation helpful? Give feedback.
All reactions