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: local policy)
Message-ID: <4818735F.60705@tangentlabs.co.uk>
Date: Wed, 30 Apr 2008 14:25:51 +0100
From: Jonathan Moss <jonathan.moss@tangentlabs.co.uk>
Organization: Tangent Labs
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: couchdb-user@incubator.apache.org
Subject: Re: efficiency of temporary views
References: <75bda7a00804300406x2758ce72qbf653992b6ae7c14@mail.gmail.com>
 <495F96C8-9C0E-43E0-A083-0901A5649058@apache.org>
 <EC6E6BA2-1763-4C9E-BD2D-9199C886AA3D@apache.org>
 <48186336.2000500@tangentlabs.co.uk>
 <D0D2DD16-15CF-4B6E-99C7-AF2FA1FE55A9@apache.org>
In-Reply-To: <D0D2DD16-15CF-4B6E-99C7-AF2FA1FE55A9@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jan Lehnardt wrote:
> Hi,
> On Apr 30, 2008, at 14:16, Jonathan Moss wrote:
>> Greetings all,
>>
>> I have been lurking for a couple of weeks now and am about to embark on
>> little project using couch DB and have a couple of questions.
>>
>> I am trying to come up with a flexible way to model an object hierarchy.
>> My current thoughts run something like
>>
>>
>> {
>>    _id: xxx
>>    _rev: yyy
>>    type: something
>>    n.e.other: foo
>>    parents: ["xxx","xxx"]
>>    children: ["yyy","yyy"]
>> }
>>
>> so a simple view (pseudo-code) to get all the children of an object
>> (with id = 123) would be:
>>
>> function(doc):
>>    if(doc.parents contains "123"){
>>       map(doc._id,doc);
>>    }
>> }
>>
>> Obviously this kind of view cannot be persisted as the value if id would
>> need to change for every document in the DB.
>>
>> Would this be terribly in-efficient as it would have to be a temporary
>> view or am I missing a trick?
>> Could I do something cunning with the key
>> field in the map function and the start/end_key get params?
>
> Yeah :)
> Do:
>
> function(doc) {
>   for(var idx in doc.parents) {
>     map(doc.parents[idx], doc);
>   }
> }
>
> and then you can use the startkey parameters to get all docs
> that have the parent "123". The Same for children and and
> anything else you need.
>
>
>> This also extends to the question of how to deal with running
>> getChildren and only returning those of a specific 'type' e.g.
>>
>> if(doc.type = 'atype' && doc.parents contains "123"){
>>    ...
>> }
>
> map([doc.parent[idx], doc.type], doc);
>
> You can have complex JSON structures as the key that
> allows you to collate by more than one attribute.
>
> Don't be shy of adding more views :)
>
> Beware though, at the moment you store the full doc
> in the view, effectively doubling data. If that is okay
> for you application and amount of data, never mind.
> If you want to be a tad more conservative, store NULL
> as the map value and retrieve only the document ids
> from the view and the document data with subsequent
> requests. Trade-offs and all that.
>
>
> Cheers
> Jan
> -- 
>
>
Thanks Jan,

That certainly makes it easier. I think I understand your warning
regarding doubling of the data. Essentially a results of a view are
pre-calculated when the view is save? So using the id's to then retrieve
the related object would be a lot more efficient in terms of storage.
The trade off being multiple requests to get the actual objects?

Would it be possible to retrieve all the documents in one request. If
the id's where continuous it would be easy to use start_key and end_key
but what if they are dis-continuous?

Thanks again,
Jon