Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 74.125.44.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=MbsEr3ZLo81Wm63KvF3B2F8IhXx4B9esIVQ1e+5ebnkvU282Id7uFCmMSVFYUWGO4W
         hOumhm1yvBYBxCajjkO89x3QUYUQu4/fQUnTlogcbtCvxBVYmunMcaep91WGmt+BE79K
         S2AGujCA8KxEalImnorEaVwbQ+IU2HxONQ6ro=
Message-ID: <e282921e0808061301k62e3d03ag677484253f9f4885@mail.gmail.com>
Date: Wed, 6 Aug 2008 13:01:54 -0700
From: "Chris Anderson" <jchris@grabb.it>
Sender: jchris@gmail.com
To: couchdb-user@incubator.apache.org
Subject: Re: when to use another document and when not to?
In-Reply-To: <A495CC9E-3B86-4C0B-82C6-86E1B764F54C@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6b6419750807141546q63431cfek69184295a1cb25b0@mail.gmail.com>
	 <DB9384FB-25ED-42F5-B4BA-FA1B1B2CFD60@gmail.com>
	 <0EEE59DA-C752-43E0-A605-31865F6E020F@apache.org>
	 <3F8F49C2-EC5C-4E6D-AFC9-854C42F7FC6D@gmail.com>
	 <13ae4dd50807271018t66ec2e78r6285c575ae16eddb@mail.gmail.com>
	 <1C0517A9-69C9-441A-A2FB-37062A76FE0A@gmail.com>
	 <13ae4dd50808060647v26e6bd14r709fc0aff72aa5b8@mail.gmail.com>
	 <B2CD78AD-4AE7-49DE-8A07-2D726810CC09@gmail.com>
	 <e282921e0808061101m7ef5eb9fh744eb2059465506d@mail.gmail.com>
	 <A495CC9E-3B86-4C0B-82C6-86E1B764F54C@gmail.com>

On Wed, Aug 6, 2008 at 12:50 PM, Sho Fukamachi <sho.fukamachi@gmail.com> wrote:
>
> Chris, what did you think about my idea of attaching/making available _rev
> information for views?
>
> Basically if we could get a _rev for every key-value output, could get an
> array of them (however massive) for the "root" of a particular view, and a
> "top" _rev for the view, it would make tracking changes much easier. I have
> been messing around and think it would be pretty easy to make a decent
> "sync" for remapping purposes if that info was available.

I think that it's a feasible way to start down the path... I'd be
curious to see what Damien thinks - he may have an eye on how to do
this in a way that could eventually be used to support remapping
natively.

My first idea of how to do this was with an event system. If there was
a way to "subscribe" to changes in a view (and which key they effect)
you could use it to mark parts of the remap index as dirty. Then to
regenerate you'd only have to recalculate the dirty parts (and also
any keys in the view which aren't in the remap - making that search
efficient might be problematic).

The event system could be prototyped by eavesdropping on the
communication between CouchDB and the view server, and firing events
based on the emitted keys.

-- 
Chris Anderson
http://jchris.mfdz.com