incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Slade <matthew.sl...@moonlight42.com>
Subject Re: View collation by one key and sorting by another key
Date Fri, 05 Aug 2011 22:00:40 GMT
Hi Zach (and everyone else)

Thanks for the info. Unfortunately my game is already big and the proposed
solution wouldn't really be suitable although _lists seem interesting and
I'll definitely investigate them. I do find this quite a limitation to
couchdb especially when one is working a lot with dated documents.

Another question I have in a similar vein:

Given a set of documents being created for transaction for the purchase of
fruit for example.

* {
"_id":"uniqueOrderId",
"dateOfPurchase": "2011-07-06T10:24:52",
"itemId": "oranges"
}*

Could one collate the view entries by the date and then reduce based off of
part of the value. ie How could I easily answer the question "*How many
oranges were sold on Wednesday*?" efficiently with potentially huge numbers
of transaction documents in my database.

ie the map function would look like:

*function(doc)
{
emit(doc.dateOfPurchase,[itemId,1]);
}*

and then the reduce function would accumulate the subset of values that it
has to reduce into a map based off of the itemId and then somehow be
converted into a list.

My attempt at this would be something like:

*function(keys, values, rereduce)
{
var map = {};

for (var i = 0;i<values.length;i++)
{

if (map[values[i][0]])
{
map[values[i][0]] += map[values[i][1]];
}
else
{
map[values[i][0]] =1;
}

}

return map;

}*

Surprisingly enough this works with a data set that is too small to warrant
a rereduce but I have no idea of how to efficiently convert that map into a
list to conform with the rules for a rereduce.

Help from anyone regarding this problem would be greatly appreciated.

Thanks

Matthew


On Fri, Aug 5, 2011 at 10:23 PM, Zachary Zolton <zachary.zolton@gmail.com>
wrote:
> Matthew,
>
> The short answer is no. CouchDB views are collated by the emitted key
> and cannot be sorted or filtered in multiple dimensions.
>
> I would solve this problem by querying the range of player documents
> whose lastDateActive falls within the past week. Then find the top 10
> players, by numberOfKills, in either the client code or in a _list
> function.
>
> You do need to consider how many players are likely to have been
> active in the past week though, since the secondary filtering will
> take more time as the number of docs resulting from the range query
> increases. So, this approach doesn't scale indefinitely, though may be
> good enough until your game becomes massively popular... (^_^
>
> Hope that makes sense!
>
>
> Cheers,
>
> Zach
>
>
> On Fri, Aug 5, 2011 at 9:27 AM, Matthew Slade
> <matthew.slade@moonlight42.com> wrote:
>> Hi All
>>
>> I've been struggling with creating a view for my game's weekly
leaderboard.
>> For simplicities sake lets assume my player document is structured in
>> the following way:
>>
>> {
>> "_id":"myuserid",
>> "lastDateActive": "2011-07-06T10:24:52",
>> "numberOfKills": 50
>> }
>>
>> If I create a map function with the "lastDateActive" as the key I can
>> use a start and an end key to collate the data and to only count users
>> that fall within the last week.
>>
>> If I create a map function with the "numberOfKills" as the key the
>> data is automatically ordered for me by kills meaning I can specify a
>> limit of 10 in the options and successfully pull out only the top 10
>> results.
>>
>> But If I create a complex key with either of these fields as the first
>> key I am unable to collate or order the data successfully since the
>> ordering can only satisfy one of the above conditions not both.
>>
>> Is there anyway that one could successfully merge these two
>> requirements and perform this sort of operation where data is collated
>> by 1 key and sorted by another?
>>
>>
>> Thank you in advance for your time and help
>>
>> Matthew
>>
>



-- 
Matthew Slade
Senior Developer
Moonlight42
(C) +27 72 655 4910
(W) +27 21 551 2409

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message