couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svein Helge Grinden <svein.helge.grin...@gmail.com>
Subject Re: Revision limit per-document
Date Sat, 18 Dec 2010 11:52:28 GMT
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.

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.

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.



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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message