incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Revision limit per-document
Date Sat, 18 Dec 2010 14:41:32 GMT
On Sat, Dec 18, 2010 at 6:52 AM, Svein Helge Grinden
<svein.helge.grinden@gmail.com> wrote:
> This may be a stupid suggestion since I'm new to CouchDB.
>
> What if a new setting called for example revs_versions_limit (or some other
> better name) was added to the config.
>
> Let's say I set the value revs_versions_limit = 10
>
> This setting would tell the compacting job not to destroy the last 10
> revision that does not have any conflicts. If let's say 4 conflicts
> i present then the compact engine should keep all the conflicts according to
> the rev_limit setting but also keep 10 revisions that has no conflict.
>

Define "last 10 versions." If you have 10 versions in conflict, does
that mean one version per conflicted branch? Or 10 per branch for a
total of 100?

> The replication engine should handle conflicting revision as it does to day
> but in addition it should also replicate the 10 last successful revisions
> according to the revs_versions_limit.

What about replication that causes some revisions to be ejected that
you wanted to keep around? For instance, you always wanted #8 for
ever, but a replication from another node introduced too many
conflicts and it gets ejected suddenly and without your direct
knowledge?

> If you have one server (server A) with revs_versions_limit = 10 and one
> other server (server B) with revs_versions_limit = 5 and you are doing
> replication between them you will keep 10 non conflicting revisions
> (versions) on server A and 5 on server B. This would off course give the
> possibility to lose some versions. If you update server B with 6 more new
> versions that are not replicated before compacting is done you would
> actually lose one version since server B only keep 5 versions. I don't think
> this is a problem since this can be avoided with just having the same limit
> on all servers you replicate to.
>
>

You can't assume you can control all servers that are replicated to.
For instance, you may have a central server and many clients replicate
in and out of that. Each client is responsible for their own node's
settings, so features that rely on cluster wide agreement are pretty
much out the window.

Also, if replication can eject old versions at will without notice,
that's not any different than the current system that only ejects
after compaction.

Bottom line, versioning is fairly domain specific. Applications or
libraries would be the appropriate place to implement something like
this.

HTH,
Paul Davis

>
> On 18 December 2010 11:27, Sebastian Cohnen
> <sebastiancohnen@googlemail.com>wrote:
>
>> This question was asked serval times in the past. And there was some
>> discussion about that too. ASFAIK there are no plans currently to implement
>> document versioning.
>>
>> I'm not sure about the implications. If you are on one node what might work
>> is to say, that you want to keep 10 versions around (even after compaction).
>> But what happens when replication is involved and you get document versions
>> replicated to your node? suddenly (after compaction) you have still 10
>> versions around, but some from your local, some from another node, some of
>> them in conflict.
>>
>> I think there were some more and other problems involved around that, but I
>> think that this feature won't be around for some time.
>>
>> On 18.12.2010, at 11:12, Svein Helge Grinden wrote:
>>
>> > Do you think document versioning is something that will be implemented in
>> future releases of CouchDB?
>> >
>> >
>> > On 18. des. 2010, at 10:54, Sebastian Cohnen <
>> sebastiancohnen@googlemail.com> wrote:
>> >
>> >> you cannot. revisions are only for concurrency control to handle
>> conflicts when replicating. If you need a document versioning you need to
>> build that by yourself.
>> >>
>> >> On 18.12.2010, at 10:45, Svein Helge Grinden wrote:
>> >>
>> >>> How can I set up CouchDB to keep the last 10 revisions of each document
>> after compaction?
>> >>>
>> >>>
>> >>> On 18. des. 2010, at 09:33, Sebastian Cohnen <
>> sebastiancohnen@googlemail.com> wrote:
>> >>>
>> >>>> just to clear things up: Setting the revision limit doesn't mean
that
>> CouchDB will keep around 10 revisions of each document. If there is no
>> conflict, only the current version is kept around after compaction.
>> >>>>
>> >>>> On 18.12.2010, at 04:30, Paul Davis wrote:
>> >>>>
>> >>>>> On Fri, Dec 17, 2010 at 9:19 PM, Svein Helge Grinden
>> >>>>> <svein.helge.grinden@gmail.com> wrote:
>> >>>>>> Hi
>> >>>>>>
>> >>>>>> I wonder if it's possible to set the revision limit per-document
and
>> not
>> >>>>>> just for the whole database?
>> >>>>>>
>> >>>>>> I would like to keep lets say 10 revisions for each document.
After
>> compact
>> >>>>>> database is ran I would still want to have up to 10 revision
of each
>> >>>>>> document.
>> >>>>>> Far as I have figured out, I can only set the total number
of
>> revisions for
>> >>>>>> the hole database.
>> >>>>>>
>> >>>>>
>> >>>>> The revs_limit is per document already. There is no database
wide
>> >>>>> revision limit.
>> >>>>>
>> >>>>> HTH,
>> >>>>> Paul Davis
>> >>>>
>> >>
>>
>>
>

Mime
View raw message