incubator-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 16:02:25 GMT
>Define "last 10 versions." If you have 10 versions in conflict, does
>hat mean one version per conflicted branch? Or 10 per branch for a
>total of 100?

Conflicts should be kept according to the revs_versions_limit. The "last 10
version" should be the ones without any conflict.
So they should be treated separately, as they are different concerns.

>What about replication that causes some revisions to be ejected that
>you wanted to keep around?

As I explained with my Server A and Server B example you can always
configure your solution to break.
If you have servers that have revs_limit = 0 and runs compact on every
update you will have trouble handling conflicts.
So if you want you can always break a solution but I think that is more a
configuration error and should not be handled by the system.

>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?

To be able to handle that we would need to have av new property on the
document you want to keep with name for example _neverDelete=true.
This would need to be set by the client as an update. You would also here
off course have the possibility to break the solution if you configure your
solution poorly.
Lets say you have _neverDelete on 5 documents but you have configured your
server to only keep 3 versions. So once again you can always break the
solution by miss configuration.

>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.

You will almost every time have scenarios where you can break a solution if
you just configure it poorly enough.
In my opinion you should not use version handling if you don't have control
over or could demand specials settings.

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

A solid library would of course be a solution, but since revisions are by
definition a type of version but today only used for concurrency today,
it should be possible to have built in version control it is just a matter
of finding a good approach. I don''t have the a solution but I think someone
will figure out a good solution for this in the future.

Thanks for all the good input. It should be pretty easy to implement a
version control based on my own library from the input I have been given.


On 18 December 2010 15:41, Paul Davis <paul.joseph.davis@gmail.com> wrote:

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