You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this is super low prio but we should, at some point, have some intrinsic measure to synchronize databases apart from some shell magic.
i guess the handling has to be different for every entity/model/table. ie. shiftentries need to be manually resolved whereas changes made to the user can be latest change is right. Angeltype changes can also be significant and in theory when an angel signed up for a shift that was changed somehow, that person needs at least to be notified, or we leave this as an option to the shift manager to decide.
All in all some kind of transaction log imo would be ideal, i guess operational transforms would be a bit overengineering it. the potential different timestamp issue can be overcome by also logging time of synchronization and working with relative time.
i propose this since i don't believe a master/master type of replication of the database doesn't quite adress all of the problems. maybe it's also sufficient to have master/master replication and have some kind of notification if something significant changed (ie. shiftentries or shifts)
The text was updated successfully, but these errors were encountered:
this is super low prio but we should, at some point, have some intrinsic measure to synchronize databases apart from some shell magic.
i guess the handling has to be different for every entity/model/table. ie. shiftentries need to be manually resolved whereas changes made to the user can be latest change is right. Angeltype changes can also be significant and in theory when an angel signed up for a shift that was changed somehow, that person needs at least to be notified, or we leave this as an option to the shift manager to decide.
All in all some kind of transaction log imo would be ideal, i guess operational transforms would be a bit overengineering it. the potential different timestamp issue can be overcome by also logging time of synchronization and working with relative time.
i propose this since i don't believe a master/master type of replication of the database doesn't quite adress all of the problems. maybe it's also sufficient to have master/master replication and have some kind of notification if something significant changed (ie. shiftentries or shifts)
The text was updated successfully, but these errors were encountered: