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 ryan.ramage@gmail.com
 designates 74.125.82.54 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=dsHHaoHst4LXsOkA+SXigoIGGgPCjjluZSiKB7VUf05SCK5VeOP9/2u+OSoE3wxhra
         24wTN5U1mNdStrKg4wwz9dyIXWbVR+jk41Y/T+h62HiAYrMUrMGxT/W3/XSTfJdjcB8N
         ICxusd+S6jdfjYA1IdBSAMMEQrep4C8Qbauys=
MIME-Version: 1.0
In-Reply-To: <loom.20101117T162904-685@post.gmane.org>
References: <loom.20101117T134738-719@post.gmane.org>
	<76A109FD-9829-4EAA-9BA1-0FAC29357EA9@apache.org>
	<loom.20101117T142932-408@post.gmane.org>
	<7D7C2F35-4630-494D-BD39-C446FCB3486E@apache.org>
	<loom.20101117T151423-281@post.gmane.org>
	<D7D21638-2CC6-4F68-B318-F3A8FC000B12@apache.org>
	<loom.20101117T162904-685@post.gmane.org>
Date: Wed, 17 Nov 2010 10:30:36 -0700
Message-ID: <AANLkTimUp6VZ02eaXLLwg6yByfTjC1uE4+hZrZd0ucPw@mail.gmail.com>
Subject: Re: Forcing document reindex
From: Ryan Ramage <ryan.ramage@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

What about a list function?

You can access the request to get query parameters (eg id needed for
the report?) and then you can iterate through the docs and build up
your relationship.

I dont know how fast it will be with the number of docs you have, but
it will be liner time (order n).

http://guide.couchdb.org/editions/1/en/lists.html


http://guide.couchdb.org/editions/1/en/lists.html

On Wed, Nov 17, 2010 at 9:13 AM, Nicolas Jessus
<nicolas.jessus@lores.org> wrote:
> All right; no one should like what they're going to read.
>
> I have a medium-sized MySQL system, which translates to a Couch with about a
> million documents of about 20 types. The system would really benefit from a
> schema-free design. The data is only weakly relational. Couch would fit really
> well, enough that I don't mind twisting its arm in a few places if need be; the
> tradeoff would be worth it.
>
> The hiccup is reporting. Some of it involves the full set of documents. Let's
> say I have 5 categories of documents involved in a report, A to E. A links to B,
> B links to C, etc. The report needs data from A, B, and E. As far as I can
> think, there's no way to do a view collation, because A and B share an ID but E
> doesn't. I can't pull a million documents from the DB to process elsewhere
> either, so that nixes simple indexing and the '_id' object values.
>
> I could however write a special view_server that will emit keys after checking
> the linked ID through an HTTP call (that's where you scream). Indexing
> performance is totally unimportant to me, DB updates are relatively few, and I
> can live with the dirty side-effects (again, the system as a whole would still
> be much cleaner than the MySQL one).
>
> With that solution I can have a map function that just handle docs of type A.
> But I still need to reindex the relevant As when B or E changes. I could simply
> listen to the change stream and force a reindex, but that doesn't work well with
> legitimate updates when the _rev number goes up at random even though the doc
> hasn't changed, and there's no auto-merge. So I'm pretty stuck.
>
> I'm not asking that this type of functionality be encouraged. It's clearly
> subverting the point of Couch. On the other hand, it doesn't seem like having a
> force-reindex function would dirty the concept, and if it's easy to code, then
> it's a shame it doesn't exist.
>
>