Aggregation group by
s12chung opened this issue · 8 comments
Found the need to group by the aggregation of tags by each user. Wanted to fyi.
Just started writing the code now for the real time aggregation. I'll put in the pull request, but the code won't be "api quality".
wasn't that bad doing the code after all. willing to work together to make an official pull request. lemme know what you think of my commit. https://github.com/s12chung/mongoid_taggable_with_context
it probably needs 3 things left:
- https://github.com/s12chung/mongoid_taggable_with_context/blob/master/lib/mongoid/taggable_with_context/aggregation_strategy/real_time.rb#L23 and https://github.com/s12chung/mongoid_taggable_with_context/blob/master/lib/mongoid/taggable_with_context/aggregation_strategy/real_time.rb#L35 could probably be optimized using map-reduce?
- implementation for map-reduce aggregation strategy
- unit test coverage
Briefly took a look at your branch. The idea is definitely useful, and I'd like to expand upon that.
It'd be more flexible if we can query by a set of conditions, e.g. get all tags where user_id = [1..10], or article.created_at = [2010.. 2011], You get the idea. This will solve your group_by problem, I think.
I'm actually working on a secret "SolrAggregator". It can do this easily. I guess map / reduce could work...? But I know real time won't work. ( That's why I moved to Solr... )
That said, I think I will implement your group_by idea. This probably covers a good portion of use cases, and SolrAggregator will have a different set of APIs to do more flexible queries.
cool. lemme know if you need any help.
+1 That feature would be great. I'm also looking for the ability to group tags based on a parent model and the ability to sort them by occurrence. Any update on your progress?
Hey guys,
Just some thoughts, please let me know how it sounds.
When I first started this gem, my primary goal was to allow tagging by context for my own needs based on mongoid_taggable.
Later I realized that mongodb's map-reduce was slow and I needed something faster, and then I came up with the "Aggregation Strategies" pattern.
However, as my project grew, I needed more advanced aggregations such as group by and facets. So I wrote some code in my project to index tags with Solr and does the searching and aggregation independent of this gem.
This leads to my realization that maybe "Aggregation Strategies" is not a good idea...
A better way, perhaps, is limit this gem only to easy store and retrieve of tags by context, and throw everything else out of the window. No aggregation what-so-ever.
This will allow other people to build new gems that target the aggregation aspect of tags based on this one. Instead of choosing strategies, you only need to choose which gem to use. Presumably, configuration would become easier as well.
Thoughts?
AQ
Hey Aaron,
I'm having a hard time imagining how the two gems interact. Specifically, how to separate storing/retrieving tags by context and aggregation. Planning the implementation seems tough.
However, decoupling the code is always a theoretically good idea. If you can do it, I don't see any reason not to.
Steve
I think this gem just need to handle store/retrieve, store some context related metadata, and expose some apis to access them. I'm working on mongoid-history refactoring at this moment. I will be able to start working on this one in about a week, stay tuned! :D
think that'll work. i'll definitely follow along =D