incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mage <m...@mage.hu>
Subject Re: replication
Date Tue, 12 Apr 2011 11:05:50 GMT
On 04/11/2011 08:40 PM, Nebu Pookins wrote:
> Are you sure the data is actually lost, as opposed to just not visible
> unless you specifically query for the conflicting versions? CouchDB
> has a deterministic "automatic winner" selection algorithm which it
> uses while it waits for your application to select a true winner. See
> http://guide.couchdb.org/draft/conflicts.html
You are right. I haven't read the whole documentation yet. The conflict
is there.

What confused me is that "standard" futon browsing doesn't show the
_conflict attributes. Neither couchrest_model does.

I can see them with a view as mentioned in the conflict chapter you linked.

I plan developing on CouchDB in 6 months and maybe that time
couchrest_model will have attributes for these conflicting revisions. Or
having only one master (write) node can be the solution for
replication-conflicts.

couchrest_model handles the other type of conflicts which happen on
parallel save of the same object. It throws an exception. That's fine
for Rails.

Now I go back reading docs, thank you.

        Mage


Mime
View raw message