couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjuan, Hector" <hector.sanj...@here.com>
Subject RE: Deleted documents being replaced by previous revisions
Date Mon, 25 Aug 2014 13:29:25 GMT
Yeah, it is acceptable that the losing version simply vanishes. It's something that mostly
happens as a result of a failover and not often at all.

All non-winning leaves should have _conflicts=true right? I guess i can just loop through
a conflicts view and remove them, but it would be nice if couchdb would simply not preserve
losing revisions based on  a configuration option.

Thanks for the quick help,

H
________________________________________
From: Robert Samuel Newson <rnewson@apache.org>
Sent: Monday, August 25, 2014 15:05
To: user@couchdb.apache.org
Subject: Re: Deleted documents being replaced by previous revisions

Hi,

CouchDB does not resolve conflicts, it preserves them until you resolve them (by deleting
them, as you’ve been doing). Reducing revs_limit will not help since that only controls
the depth of the revision tree and not its breadth.

If you are updating the same document at two different sites, and then replicating them, you
will introduce conflicts. This is something you need to account for in your application. If
user A updates document Foo on site 1 and user B updates document Foo on site 2 then, after
replication, both sites will present either user A or user B’s update, and the other is
a losing revision (preserved but hidden). Is it acceptable in your application for one of
these user writes to effectively vanish? Or should something be done to document Foo to reconcile
the fact it was edited differently by two different users concurrently?

B.


On 25 Aug 2014, at 13:47, Sanjuan, Hector <hector.sanjuan@here.com> wrote:

> Any sensible workaround in order to not leaving any leaf behind? Whatever comes out of
the couchdb conflict resolution is fine. The content of previous/conflicted revisions is not
really important and not something I would like to go back to.
>
> Both masters receive writes independently. I am tempted to reduce _revs_limit, but it
sounds it will be a bad idea if my masters lose connectivity to each-other for some time (they
sit on different DCs).
>
> H
>
> ________________________________________
> From: Robert Samuel Newson <rnewson@apache.org>
> Sent: Monday, August 25, 2014 14:26
> To: user@couchdb.apache.org
> Subject: Re: Deleted documents being replaced by previous revisions
>
> Hi,
>
> What’s happening here is your document is conflicted. That is, there are multiple 'latest'
revisions to choose from. In this situation, CouchDB chooses one of them to present to you
when you do GET /dbname/docid. When you then delete that revision, you are promoting one of
the others.
>
> The common way to introduce conflicts is to edit the same document at multiple locations
and then replicate, which would appear to be your setup. Are you allowing writes to both masters?
>
> It is only non-latest (we say "non-leaf") revisions that are removed by compaction, CouchDB
preserves all of the latest revisions (as we do not know which edit or edits you want to keep),
so the revs limit of 1000 that you mention is in fact unrelated to your issue.
>
> B.
>
>
>
> On 25 Aug 2014, at 13:16, Sanjuan, Hector <hector.sanjuan@here.com> wrote:
>
>> Hi,
>>
>> we are running a couchdb 1.5.0 setup with master-master replication.
>>
>> I am observing that sometimes, a document has multiple revisions stored,
>> and when deleting the most current one, a previous one replaces it
>> and becomes available.
>>
>> The old revision numbers that are available are non-consecutives (i.e.
>> rev 1234 would be replaced by 742). Querying the revs would come back
>> with a list of non-consecutive revisions, for which a full document
>> exists even after compactation.
>>
>> As I understand it, old revision records are kept around for
>> replication and its contents subject to disappear on compactation. I'd
>> assume writing a document 1000 times and then issuing a DELETE would
>> mark it as deleted and inform of this on subsequent GETs.
>>
>> Has anyone come across anything similar? I have searched around without
>> much luck.
>>
>> Is this maybe related to replication conflicts were the conflict is
>> resolved but the conflicting revisions left behind?
>>
>> As of now, getting the documents truly deleted means issuing DELETE
>> a few times until every leftover revision is gone. Of course this only
>> shows up randomly here and there, and in small tests couchdb deletes
>> and works as expected.
>>
>> Thanks,
>>
>> Hector
>


Mime
View raw message