4 ms·

"Conflict resolution is last write wins, but at the individual property level (two devices can update a to-do task and update different properties)." Depending

"Conflict resolution is last write wins, but at the individual property level (two devices can update a to-do task and update different properties)." Depending on your use case property by property conflict resolution works great but it can also go horrible wrong with some data. Do you have timestamps on each property?

heavenlyblue 8y ago
I would assume every diff has a timestamp. And since you can diff properties separately then it works correctly. I would be curious about another scenario: what about several devices generating a new password for a website? Or instead - creating a note with the same name? The one that is going to be saved is the last one - that is true. But it implies there's some transparent data loss in the background (you could still get those from the log, of course). How do you deal with those "soft" conflicts in the UI? Is there any learning curve for the user to accept that any changes could be rolled back? How do you display that so that the user wouldn't assume the data was lost?
- Normal_gaussian 8y ago
  With respect to the notes of the same name - you can key the items with a generated id and "namespace" the keys with a journal specific id to avoid conflicts. In this way two notes having the same name is 'ok' as they have different keys. It would help to have a user guided merge feature that can be manually triggered by combining items (not just on conflict)
  - allenu 8y ago
    This is exactly what I'm doing with my solution.
- allenu 8y ago
  With my system, I create a UUID for each entry, so I'm guaranteed uniqueness there. The other properties (task name) can be whatever you want. You're right that it gets even more tricky if you are doing key=>value pairs and are expecting that the key is something that may not be unique across devices (i.e. two devices using the same website domain as they key would lead to a conflict).
- jayd16 8y ago
  Hmm, something nice about this change log solution is that merge is built in by design. You could very happily default to all new collection items start with a UUID despite things like user definable item names. Normally this might be annoying but with merge as a first class citizen its easy to add a "merge these items" feature. Not only is there no hidden data loss, but it also adds the nifty feature of being able to merge totally unique item.
allenu 8y ago
Yes, every diff has a timestamp. The clocks aren't synced across devices, but the assumption is that they are "close enough" such that a user isn't going to do something like mark a task as done on device A and within the clock delta jump to device B and mark it as "not done". Conflict resolution falls apart if there are multiple users on multiple devices, but my assumption with my solution is that it's only to be used by a single user across multiple devices.
- bradknowles 8y ago
  How accurate is your timesync? Do you use NTP across the board, and if so, how often do you check with your upstream clock servers to see if you might need to make some minor adjustments? What happens if two different devices try to make updates within the window of your timesync error? Who wins then? Because they both think that they're the latest and therefore their write should win.
  - allenu 8y ago
    I don't do anything like that. I just rely on the device's clock. Again, for my simple needs (to-do list), it works fine. It could be a problem if you have a device with the wrong time, but even then it would require a single user to be making lots of changes on the same property of the same object within a very small window of time, which for a to-do app is very, very unlikely. I didn't want to solve problems I didn't have.
    - maxxxxx 8y ago
      Sounds like you created a simple, pragmatic solution for your use case. Which is exactly what you should do. But the method probably can't be applied to mission critical systems without changes.
    - allenu 8y ago
      My solution was designed for a very narrow use case where there is one user and multiple devices. The main reason I designed it because I did not want to stand up a cloud service for storing user info. I wanted to offload that responsibility to a file sharing system like Dropbox or OneDrive. It's not meant for anything beyond a very simple use case.

heavenlyblue 8y ago

I would assume every diff has a timestamp. And since you can diff properties separately then it works correctly. I would be curious about another scenario: what about several devices generating a new password for a website? Or instead - creating a note with the same name? The one that is going to be saved is the last one - that is true. But it implies there's some transparent data loss in the background (you could still get those from the log, of course). How do you deal with those "soft" conflicts in the UI? Is there any learning curve for the user to accept that any changes could be rolled back? How do you display that so that the user wouldn't assume the data was lost?

Normal_gaussian 8y ago
With respect to the notes of the same name - you can key the items with a generated id and "namespace" the keys with a journal specific id to avoid conflicts. In this way two notes having the same name is 'ok' as they have different keys. It would help to have a user guided merge feature that can be manually triggered by combining items (not just on conflict)
- allenu 8y ago
  This is exactly what I'm doing with my solution.
allenu 8y ago
With my system, I create a UUID for each entry, so I'm guaranteed uniqueness there. The other properties (task name) can be whatever you want. You're right that it gets even more tricky if you are doing key=>value pairs and are expecting that the key is something that may not be unique across devices (i.e. two devices using the same website domain as they key would lead to a conflict).
jayd16 8y ago
Hmm, something nice about this change log solution is that merge is built in by design. You could very happily default to all new collection items start with a UUID despite things like user definable item names. Normally this might be annoying but with merge as a first class citizen its easy to add a "merge these items" feature. Not only is there no hidden data loss, but it also adds the nifty feature of being able to merge totally unique item.

allenu 8y ago

Yes, every diff has a timestamp. The clocks aren't synced across devices, but the assumption is that they are "close enough" such that a user isn't going to do something like mark a task as done on device A and within the clock delta jump to device B and mark it as "not done". Conflict resolution falls apart if there are multiple users on multiple devices, but my assumption with my solution is that it's only to be used by a single user across multiple devices.

bradknowles 8y ago
How accurate is your timesync? Do you use NTP across the board, and if so, how often do you check with your upstream clock servers to see if you might need to make some minor adjustments? What happens if two different devices try to make updates within the window of your timesync error? Who wins then? Because they both think that they're the latest and therefore their write should win.
- allenu 8y ago
  I don't do anything like that. I just rely on the device's clock. Again, for my simple needs (to-do list), it works fine. It could be a problem if you have a device with the wrong time, but even then it would require a single user to be making lots of changes on the same property of the same object within a very small window of time, which for a to-do app is very, very unlikely. I didn't want to solve problems I didn't have.
  - maxxxxx 8y ago
    Sounds like you created a simple, pragmatic solution for your use case. Which is exactly what you should do. But the method probably can't be applied to mission critical systems without changes.
  - allenu 8y ago
    My solution was designed for a very narrow use case where there is one user and multiple devices. The main reason I designed it because I did not want to stand up a cloud service for storing user info. I wanted to offload that responsibility to a file sharing system like Dropbox or OneDrive. It's not meant for anything beyond a very simple use case.