Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <1302338725.29780.6.camel@otto.amantes>
References: <1302198233.3064.15.camel@ana.amantes>
 <BANLkTimXZPQNmvunkQUWfYx8bqU_39HotQ@mail.gmail.com>
 <1302338725.29780.6.camel@otto.amantes>
From: Mark Hahn <mark@boutiquing.com>
Date: Sat, 9 Apr 2011 11:50:59 -0700
Message-ID: <BANLkTimN5=o4DE1kcSjTEQ41k_=Lh_5T-g@mail.gmail.com>
Subject: Re: change notifications question
To: Thomas Vander Stichele <svsamoht@gmail.com>
Cc: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=bcaec51b176bf952d404a080d340

--bcaec51b176bf952d404a080d340
Content-Type: text/plain; charset=ISO-8859-1

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


On Sat, Apr 9, 2011 at 1:45 AM, Thomas Vander Stichele
<svsamoht@gmail.com>wrote:

> On Thu, 2011-04-07 at 11:19 -0700, Mark Hahn wrote:
> > You are not even guaranteed the old version will be there.
>
> I would be ok with that, it doesn't seem to be a big problem in
> practice.  (Although it's strange to me that all the infrastructure is
> there to have document revisions, but we have no control over how much
> history we want couchdb to keep.  Seems like a relatively
> straightforward next step).
>
> >   You need
> > to build history into your app.
>
> Can you be a bit more explicit about what you mean?
>
> It sounds like you say I should re-write CouchDB's revisioning/history
> approach in my app just to get around the fact that couchdb has no
> controls for history.  I might as well build it on top of anything else
> than couchdb no ? :)
>
> Thanks
> Thomas
>
>
>


-- 
Mark Hahn
Website Manager
mark@boutiquing.com
949-229-1012

--bcaec51b176bf952d404a080d340--