Hi Gordon, Thanks for your feedback! Some follow up questions below:
For example, with search I can specify something like this to generate my > input to map-reduce: > > p:foo AND t:bar (give me all the objects whose parent "p" is foo and that > hav tag "t" of bar). > > So that would get fed to map-reduce where additional processing (think > filtering, sorting, pagination) is done. > > I can do the same thing with secondary indexes but would have to move some > of that into map. > > So in this case I would use secondary indexes to grab all of the items > whose parent "p" is "foo". This would generate the input phase and at that > point I would have to use map to filter out all of the items that did not > contain the tag "t" of "bar". > > It is doable, but not as performant as I think it could be. > So to be clear, this is mainly about performance, not convenience? In other words, you don't mind writing your own map function, so long as it is fast? Also, lets say that part 1 of the query is getting a list of keys where "p" == "foo", part 2 is turning those keys into objects, and part 3 is filtering those objects. Are all parts too slow for your application, or is only a specific part of the query too slow? Hope that makes sense, this is a nuanced point. -- Rusty Klophaus (@rustyio) *Basho Technologies, Inc.* www.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
