Hey Christoph,
> When looking at the sample I noticed that a profile document gets created > as part of the loginWithFacebook function. That works well when the user > truly doesn’t exist in the database but what happens when the user logs > back in and already has a profile on the remote database? > Yes, the system can create a conflict here. However -- and this is a key point in the Couchbase Lite design -- the system will deterministically pick a winner from those conflicting revisions, and continue on using the winning revision. One key point here is the fact that the winning revision of a conflict is chosen *deterministically. * When I first started wrapping my head around Couchbase Lite, this was a huge "aha moment" for me. What it means is that there is an algorithm that specifies how the the winning revision of a conflict will be chosen, and all nodes in the system apply the same algorithm, and will therefore get the same result. So to make it more concrete .. Suppose you have two devices: iphone ipad and suppose on the iphone, a revision is created: doc id: [email protected] rev id: 1-324 and on the ipad: doc id: [email protected] rev id: 1-989 after these devices sync, you end up with this on *both* the iphone and ipad: [image: Inline image 1] It's key to realize that this will be the state of affairs on both devices after sync -- due to the fact it's a deterministic algorithm, we know that both devices will have picked the same winning revision. What this means is: * If you call getDocument("[email protected]").getCurrentRevisionID() on either device, you will get rev 1-929. * If you add a new revision to the doc "[email protected]" on the ipad, say 2-455, that will happen on top of 1-929, so your rev history will be [2-455, 1-929] So revision 1-324 will still be there, but will essentially be a dead branch on the revision tree and ignored. At this point, you might be thinking .. don't I have to resolve this conflict? Don't I have to clean up this mess? Actually, you can, and you should -- but you don't have to. The system will happily continue with a conflict in its revision tree, and it won't mess anything up. However, you should clean them up if possible, since it will waste some space if you don't. You also might be wondering, but what if rev 1-324 had the user's website address in the profile and 1-929 did not, is that information going to be lost? Nope, it won't be lost, but it will remain hidden indefinitely, so your user will effectively never see it. To make sure that information makes it into your app, you'll need to write some code that looks for conflicts, and does some application specific merging to merge the information from the deleted revision. We have some examples of that I can dig up if you need it. Asked a bit differently, our solution requires a profile document however > when the user logs in from a device, we want to check whether a profile > document already exists, sync first and then use it or create one if it > doesn’t exist already? > Well, if you take the approach used in TodoLite and just allow a potential conflict, you can worry less about having to make sure the profile already exists somewhere else or not. Depending on your business requirements, you may need to actively handle those conflicts and have business specific merging rules. -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/CACSSHCEG%3DkmYHCq7mn9%3DVxaq33dSQeTEJRLkdDsOQpGJLrg4Rw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
