Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of devnullian@gmail.com
 designates 209.85.198.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=gWG8X35DFtrqdcKGbesrjD7omeTW2mZKEanr6T7Ma/Jt0E+X0BLDdKj2l3+cfeBa3K
         euTtTK8c476GOqSN8jn+ZD5oX+iW8NZqgFK1Bx1I+pN8YL8GgKReNMXhmrAYlnMKrR48
         WvZgvx/pP0io81a3/I6myZVkpakOyHQaiXupU=
Message-ID: <9f01072b0901060922h4c0a8cbajb546b3e616eae3fa@mail.gmail.com>
Date: Tue, 6 Jan 2009 10:22:22 -0700
From: "Daniel DeLeo" <devnullian@gmail.com>
To: user@couchdb.apache.org
Subject: Re: Proposal: Extending immutability
In-Reply-To: <ec7a93a0901052135q7205c383sfad414d2a8e0d7c3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_242067_7646946.1231262542464"
References: <9F8937BF-9332-416C-BA01-4B1D001EA029@gmail.com>
	 <C1645AC6-ACF5-45AF-96B9-906189EFE424@aptela.com>
	 <4EFE48A5-5D07-40D9-AF3C-C67802BE6955@gmail.com>
	 <e282921e0901051903m30e9cce6i5133d2f9866c0475@mail.gmail.com>
	 <4A0B4B90-DF50-4861-B808-1F39A69DAEC5@gmail.com>
	 <e282921e0901052007v53386c52he0cdc2c30614a36a@mail.gmail.com>
	 <ec7a93a0901052135q7205c383sfad414d2a8e0d7c3@mail.gmail.com>

------=_Part_242067_7646946.1231262542464
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Stop me if there's a better way to do this already, but:

One possible use case for this feature could be an app with a drawing
component, maybe a powerpoint-type thing, where the images are created and
stored as SVGs, but viewed (or previewed or thumbnailed) as pngs.  The app
would know to recreate the png or at least test for changes to the SVG when
couch reports an updated rev.

Another use case could be a blog using markdown, possibly with markdown
comments.  The app could create and cache the HTML version for faster
access, updating only when the source documents change.

On the other hand, with view code like 'emit([doc.whatever, doc._id,
doc._rev], null)' and using include_docs when the whole document is needed,
one could accomplish this without requiring anything new from couch, albeit
in a less elegant way.

Just throwing it out there, but I think these use cases at least show how
such a feature could be valuable.

Cheers,
Dan DeLeo

On Mon, Jan 5, 2009 at 10:35 PM, Randall Leeds <randall.leeds@gmail.com>wrote:

> On Mon, Jan 5, 2009 at 23:07, Chris Anderson <jchris@gmail.com> wrote:
>
> > Again, I'm not sure that having the rev available on the view row
> > makes a difference. The indexer cares about the keys and values, if
> > they've changed, they've changed.
> >
>
> This is true. However, it could be very expensive to compare the keys and
> values to see if they've changed. You could put the burden on the
> application developer to get around this by including some checksum in the
> view, or just leverage the immutability of CouchDB's revisions and provide
> it for free by returning the revision. I like this idea because it enables
> this blurry use case we're all sort of imagining together while keeping the
> actual map function focused on the real data that needs to be returned (as
> opposed to metadata that enables some slick performance gain).
>
> -Randall
>

------=_Part_242067_7646946.1231262542464--