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