From user-return-14260-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sat Dec 18 12:15:27 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 96559 invoked from network); 18 Dec 2010 12:15:27 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Dec 2010 12:15:27 -0000 Received: (qmail 18030 invoked by uid 500); 18 Dec 2010 12:15:25 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 17932 invoked by uid 500); 18 Dec 2010 12:15:25 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 17778 invoked by uid 99); 18 Dec 2010 12:15:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Dec 2010 12:15:24 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dionne@dionne-associates.com designates 69.89.21.8 as permitted sender) Received: from [69.89.21.8] (HELO oproxy3-pub.bluehost.com) (69.89.21.8) by apache.org (qpsmtpd/0.29) with SMTP; Sat, 18 Dec 2010 12:15:16 +0000 Received: (qmail 1279 invoked by uid 0); 18 Dec 2010 12:14:55 -0000 Received: from unknown (HELO host183.hostmonster.com) (74.220.207.183) by oproxy3.bluehost.com with SMTP; 18 Dec 2010 12:14:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=dionne-associates.com; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=VqpTsX8oJKspAW1uA8iZtx6xv/MayEcRk4VE5UohFUSXESTVkvrAz5uNqkXqC+V+FFLE77DNgSJB1lennbU6DECXB7656ZRafPQxiEPE+xSSGW//JsAXE0jzVg5B66xB; Received: from adsl-99-61-108-131.dsl.wlfrct.sbcglobal.net ([99.61.108.131] helo=[192.168.1.110]) by host183.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1PTvgc-0001G8-I7 for user@couchdb.apache.org; Sat, 18 Dec 2010 05:14:55 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Revision limit per-document From: Robert Dionne In-Reply-To: Date: Sat, 18 Dec 2010 07:14:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1DB7B296-66AD-4AB0-A426-9DC1663C2848@dionne-associates.com> References: <34F3CEC1-126B-4A5A-AD25-853E647B1871@googlemail.com> <357A904C-D2A8-4D79-8CE0-FF782665EC42@gmail.com> <10158A92-E1BC-4ACB-8D39-7FE26D321660@googlemail.com> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1082) X-Identified-User: {2551:host183.hostmonster.com:dionneas:dionne-associates.com} {sentby:smtp auth 99.61.108.131 authed with dionne@dionne-associates.com} X-Virus-Checked: Checked by ClamAV on apache.org I think it's doable, but it would take a lot of rework to get it right, = given that it was not designed for version control but rather for = concurrency control. On Dec 18, 2010, at 6:52 AM, Svein Helge Grinden wrote: > This may be a stupid suggestion since I'm new to CouchDB. >=20 > What if a new setting called for example revs_versions_limit (or some = other > better name) was added to the config. >=20 > Let's say I set the value revs_versions_limit =3D 10 >=20 > 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. >=20 > 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. >=20 > If you have one server (server A) with revs_versions_limit =3D 10 and = one > other server (server B) with revs_versions_limit =3D 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. >=20 >=20 >=20 > On 18 December 2010 11:27, Sebastian Cohnen > wrote: >=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> On 18.12.2010, at 11:12, Svein Helge Grinden wrote: >>=20 >>> Do you think document versioning is something that will be = implemented in >> future releases of CouchDB? >>>=20 >>>=20 >>> On 18. des. 2010, at 10:54, Sebastian Cohnen < >> sebastiancohnen@googlemail.com> wrote: >>>=20 >>>> 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. >>>>=20 >>>> On 18.12.2010, at 10:45, Svein Helge Grinden wrote: >>>>=20 >>>>> How can I set up CouchDB to keep the last 10 revisions of each = document >> after compaction? >>>>>=20 >>>>>=20 >>>>> On 18. des. 2010, at 09:33, Sebastian Cohnen < >> sebastiancohnen@googlemail.com> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> On 18.12.2010, at 04:30, Paul Davis wrote: >>>>>>=20 >>>>>>> On Fri, Dec 17, 2010 at 9:19 PM, Svein Helge Grinden >>>>>>> wrote: >>>>>>>> Hi >>>>>>>>=20 >>>>>>>> I wonder if it's possible to set the revision limit = per-document and >> not >>>>>>>> just for the whole database? >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>=20 >>>>>>> The revs_limit is per document already. There is no database = wide >>>>>>> revision limit. >>>>>>>=20 >>>>>>> HTH, >>>>>>> Paul Davis >>>>>>=20 >>>>=20 >>=20 >>=20