On Tue, 12 Jan 2010, Jaap Karssenberg wrote:
> On Tue, Jan 12, 2010 at 7:13 PM, Raphael Hertzog <email address hidden> wrote:
> >> * Keep "last synced version" property, either sequential id or timestamp
> >> * If there is a conflict because a page was modified in both places just move the oldest out of the way to a timestamped backup file - maybe prompt the user first.
> >
> > In theory couchdb does this for us precisely.
>
> I guess this works when you use couchdb as the native storage. But I
> guess you will have to check client side for remote changes and deal
> with them if you still have uncomitted changes yourself. Or am I
> missing a couchdb feature ?
You deal with conflicts after they have happened, not in real time.
The DB stores all the conflicting version and from time to time, you have
go over the known conflicts and resolve them. They call that "Eventual
Consistency".
On Tue, 12 Jan 2010, Jaap Karssenberg wrote:
> On Tue, Jan 12, 2010 at 7:13 PM, Raphael Hertzog <email address hidden> wrote:
> >> * Keep "last synced version" property, either sequential id or timestamp
> >> * If there is a conflict because a page was modified in both places just move the oldest out of the way to a timestamped backup file - maybe prompt the user first.
> >
> > In theory couchdb does this for us precisely.
>
> I guess this works when you use couchdb as the native storage. But I
> guess you will have to check client side for remote changes and deal
> with them if you still have uncomitted changes yourself. Or am I
> missing a couchdb feature ?
http:// books.couchdb. org/relax/ reference/ conflict- management
You deal with conflicts after they have happened, not in real time.
The DB stores all the conflicting version and from time to time, you have
go over the known conflicts and resolve them. They call that "Eventual
Consistency".
Cheers,
--
Raphaël Hertzog