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.
