couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: proposed replication rev history changes
Date Sun, 08 Feb 2009 16:10:01 GMT
On Sun, Feb 8, 2009 at 6:07 AM, Patrick Antivackis
<patrick.antivackis@gmail.com> wrote:
> 2009/2/8 Damien Katz <damien@apache.org>
>
>> You got everything right except this. It doesn't solve the problem, because
>> on another node, I could have a document that looked like ["1-foo" "2-bif"].
>> That is a real edit conflict that wouldn't be caught by what I think you are
>> proposing.
>>
>
> That's right,  there is a real edit conflict, but at least couchdb can
> detect it based on the first revision reference that is always kept.
> If you not keep the reference of the first revision you can arrive to :
> BaseA : ["1-foo"]
> BaseB : empty
> Replication :
> BaseA : ["1-foo"]
> BaseB : ["1-foo"]
> Life goes on :
> BaseA : ["1-foo" "2-bar" "3-baz" "4-biz"] but as it's trimmed to 3 you only
> keep ["2-bar" "3-baz" "4-biz"]
> BaseB : ["1-foo" "2-bad" "3-baf" "4-bif"] but as it's trimmed to 3 you only
> keep ["2-bad" "3-baf" "4-bif"]
> New replication :
> ????? same Id but no common revision, what we do ? And couch can not even
> help to say if it was same doc or not at the origin.
>

Patrick,

I'm pretty sure i see where you're coming from, but can you explain
what would happen if the same document ID were created on two servers?
Each server would have a different 'first rev' so who's first rev
would be carried on in the future?

> This is used during conflict detection to figure out if 2 tree fragments
>> overlap. We don't actually store a sequential number for each revision, we
>> store a revision tree of numbers, with the root of the tree being the offset
>> from 0 where it was trimmed (technically it's stemmed).
>>
>
> You are right, keep trace of the numbrer of the revision is indeed important
> especially when a same origin document in updated on different nodes.But
> couldn't it be replace bu a timestamp, this is sequential too and give even
> more information.
>
>
>> Sometimes people can deal with spurious conflicts. This gives you the
>> option. If you don't want spurious conflicts, don't use this feature.
>>
>> And if you want the same document to be editted over and over, 100s of
>> thousands of times, this is really the only option. The revision history
>> will get too big and slow down updates tremendously.
>>
>> Sure but  I would say it's different use cases. Record management for
> examples needs to keep track of changes during a period of time. And in all
> CMS/ECM i have worked on, clean up of version is done on time base more than
> on number of revision having occured.
>

HTH,
Paul Davis

Mime
View raw message