From user-return-15764-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Apr 10 00:23:21 2011 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 1570 invoked from network); 10 Apr 2011 00:23:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Apr 2011 00:23:21 -0000 Received: (qmail 13801 invoked by uid 500); 10 Apr 2011 00:23:19 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 13763 invoked by uid 500); 10 Apr 2011 00:23:19 -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 13755 invoked by uid 99); 10 Apr 2011 00:23:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Apr 2011 00:23:19 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED X-Spam-Check-By: apache.org Received-SPF: unknown (nike.apache.org: error in processing during lookup of N.Breunese@vpro.nl) Received: from [145.58.30.185] (HELO out1b.mail.omroep.nl) (145.58.30.185) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Apr 2011 00:23:12 +0000 Received: from localhost (ou1bclean [10.10.30.159]) by out1b.mail.omroep.nl (Postfix MTA - NPO ICT) with ESMTP id CBD043000362 for ; Sun, 10 Apr 2011 02:22:51 +0200 (CEST) X-Virus-Scanned: NPO ICT Received: from zeefje.vpro.nl (zeefje.vpro.nl [145.58.168.41]) by out1b.mail.omroep.nl (Postfix MTA - NPO ICT) with ESMTP id ADC1130000BA for ; Sun, 10 Apr 2011 02:22:51 +0200 (CEST) X-ASG-Debug-ID: 1302394970-0084845ad12b35a0001-z14J5S Received: from mail.vpro.nl (mail.vpro.nl [145.58.171.81]) by zeefje.vpro.nl with ESMTP id 4Ss9LWQt48mV3VBH for ; Sun, 10 Apr 2011 02:22:50 +0200 (CEST) X-Barracuda-Envelope-From: N.Breunese@vpro.nl X-Barracuda-Apparent-Source-IP: 145.58.171.81 Received: from VS-EX-01.intra.vpro.nl ([145.58.171.81]) by VS-EX-01.intra.vpro.nl ([145.58.171.81]) with mapi; Sun, 10 Apr 2011 02:22:49 +0200 From: Nils Breunese To: "user@couchdb.apache.org" Date: Sun, 10 Apr 2011 02:21:11 +0200 Subject: RE: change notifications question Thread-Topic: change notifications question X-ASG-Orig-Subj: RE: change notifications question Thread-Index: Acv25y+v2Wt1MkEdTRKuirNWo9gk6AALgKZk Message-ID: References: <1302198233.3064.15.camel@ana.amantes> <1302338725.29780.6.camel@otto.amantes>, In-Reply-To: Accept-Language: nl-NL Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail.vpro.nl[145.58.171.81] X-Barracuda-Start-Time: 1302394970 X-Barracuda-URL: http://145.58.168.41:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at vpro.nl X-Barracuda-Bayes: INNOCENT GLOBAL 0.5031 1.0000 0.7500 X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.60397 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Checked: Checked by ClamAV on apache.org This blog post suggests storing versions as attachments: Simple Document Versioning with CouchDB http://blog.couchbase.com/simple-document-versioning-with-couchdb Nils. ________________________________________ Van: Mark Hahn [mark@boutiquing.com] Verzonden: zaterdag 9 april 2011 20:50 Aan: Thomas Vander Stichele CC: user@couchdb.apache.org Onderwerp: Re: change notifications question > I might as well build it on top of anything else than couchdb no ? :) If the only feature you care about in your db is versioning then you are correct, all non-versioning dbs are equal. I personally love using couch for the many reasons discussed. I find it so much less painful than a structured db. If you are willing to build the versioning in your app then there is a simple solution, IMHO. Save new versions as new docs, not revisions. Couc= h doesn't utilize differencing of versions so there is no performance hit. Keep your own ID that is separate from the couch ID. You can create a vie= w that links to the previous "version" and you can pull both docs in one query. Replication will work the same. DB size growth will be the same. You will need to do your own deleting at your leisure but you will have full control with your own algorithm. The coding of this would be trivial compared to changing the erlang implementation of couch and you wouldn't be risking losing support by forking. I think I could do it in a day or so. It would be fun. ------------------------------------------------------------------------ VPRO www.vpro.nl ------------------------------------------------------------------------