Its hard to separate conflict resolution from picking the id mechanisms (using uuid is generally considered a bad idea for structured data). if you want 'change it once change it everywhere' then you use the password as the key and you can disregard conflicts (which will be rare), if you want individual password entries per form then you use the url|form|field, if you want both then you use the most common situation (like url|form|field) and have to do a batch update. usually these are fairly obvious (visits = url, tabs = url + id, form fields = address to form field, or possibly a document per form / url)
On 26 July 2013 20:09, Andreas Gal <[email protected]> wrote: > I have no opinion on conflict resolution. Many good approaches are valid. > I don't care about which one we use per type. Last write is fine IMO for > everything. Which key approach we use is critical, however. Otherwise > finding the dupes will be difficult in the client. > > Andreas > > Sent from Mobile. > > On Jul 26, 2013, at 12:06, Lloyd Hilaiel <[email protected]> wrote: > > On Jul 26, 2013, at 1:03 PM, Andreas Gal <[email protected]> wrote: > > In short, what I heard yesterday ("lets copy data in case of conflict") is > a noble theory, but I am afraid wrong in practice, and I would like to hear > comments on the observation above. > > > Sounds like you're refining that theory. That conflict resolution is type > specific. > > For passwords - most recent change wins. > > For bookmarks, tabs and history - favor duplication over deletion. > > ? > > lloyd > > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
