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: local policy)
Message-ID: <4A225B26.80305@tmit.bme.hu>
Date: Sun, 31 May 2009 12:25:42 +0200
From: Zoltan Lajos Kis <kiszl@tmit.bme.hu>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Many-to-many views sorted and paginated
References: <4A22584F.6040008@tmit.bme.hu>
In-Reply-To: <4A22584F.6040008@tmit.bme.hu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Maciej Dziardziel wrote:
> Zoltan Lajos Kis wrote:
>
>> I understand that if I stored registration data within event documents,
>> e.g. by listing userid's, this would be as simple as emitting keys like
>> [event.registered[i], event.date, event.location] and then querying with
>> "?startkey=[userid]&endkey=[userid, {}]&limit=20"
>>
>> However, for me it seems more appropriate from several aspects not to
>> store the registration data within the event documents.
>
> You could store those data in both places.
Perhaps this is part of the things "to be unlearnt", but I still don't 
favor the idea of this kind of redundancy. Also it feels more natural to 
me to store registrations along with user data, as this way I only have 
single-writer documents and can limit write access on events.
>
>
>
>> 1. Using a view, which emits ( [event.date, event.location], event.id ),
>> I get the list of all eventid's, properly sorted (without the 
>> documents).
>
> Depending on the number of events this can kill your perfomance - 
> downloading large amount of data (reading them first from disk)
> looks for me like worst possible solution.
>
This was my fear as well... I may be able to introduce some 
restrictions, for example showing user events only for a given week / 
month. That
way I can use a key-range for this view as well, limiting the ids to be 
emitted.

Zoltan.