On Fri, Nov 13, 2009 at 02:22:11PM -0600, Alex P wrote: > 1. server 1 is asked for a copy of document foo, and stores revision > 1-fedbca in its local cache > 2. server 2 is asked to change document foo, foo gets revision of 2-abcdef, > and is stored in server 2's cache > 3. server 1 is asked to modify document foo, retrieves it from local cache, > and attempts to save it with rev 1-fedbca, causing a conflict > > assuming that this is a topology that we want to have for the time being, > what are the group's thoughts on this resolution strategy: > > - in addition to storing the actual document, keep a record of which fields > are being modified (call this copy a) > - when a conflict is detected, retrieve couchdb's copy (call it copy b), and > apply the changed fields 'only' from copy a, to copy b. > - save copy b with the net difference. > > thoughts?
Sounds reasonable to me. To those saying "don't cache" or "do a HEAD request first", I would point out that there is still a race window when conflicts can be introduced into the database (*). Therefore IMO it's better to handle conflicts properly in the first place, and then you gain the ability to do "disconnected" caching for free. Regards, Brian. (*) If the writers are writing to different backends which replicate to each other, then you'll get conflicts. If the writers are writing to the same database using "all_or_nothing":true then you'll get conflicts. If the writers are writing to the same database using PUT then the second update will be rejected entirely with a 409 error. See: http://wiki.apache.org/couchdb/Replication_and_conflicts
