On Aug 10, 5:09 pm, Colin Law <[email protected]> wrote: > On 10 August 2011 13:49, Robert Walker <[email protected]> wrote: > > > Owain wrote in post #1015933: > >> My application is gradually being refined and it is becoming necessary > >> to provide some statistics. I don't really want to add all of these > >> into the main application logic since it is not critical. I would > >> like to "observe" a bunch of models and classes and increment and > >> decrement counters. So rather than have a bit of hideous AR finds to > >> show me the number of orders by month I can observe the AR callbacks > >> on event and increment "August 2011 Orders". I would also need to be > >> able to reset via a Rake task or something similar. > > >> Has someone come across a Gem that provides this sort of functionality > >> before I go and write it? > > > [snipped lots of good stuff from Robert] > > +1 to what Robert suggested, *but* first I would define methods of the > models to provide the stats you are looking for (or define a new > statistics class that provides the methods) then initially just do > them as AR queries. You have said these will be 'hideous' but they > should not be difficult to code. This may apparently be an > inefficient way to achieve the answers but it will be simple and will > get you functioning (and testable) code quickly and easily. Then, in > the fullness of time, if it becomes clear that they take too long to > run, you can worry about optimising the execution by running data > mining techniques as Robert has suggested. As these will involve > refactoring of the methods you started with it will have minimal (if > any) effect on the rest of the app. >
Colin, That was exactly my first thought but I think the statistics are really just observing the application, not the application itself. So rather than having a whole load of class methods on the models to provide the data I can use an Observer class per model, or even better one Observer class that collects the statistics for all of the relevant models. So only the statistics Observer class ever changes as the requirements for the statistics changes over time. The idea came from the article http://railstips.org/blog/archives/2011/06/28/counters-everywhere/ by John Nunemaker (I recommend his posts for some great ideas). He has coded this in a MongoDB environment, basically a key-value pair. Here is some pseudo code not implemented, class Amodel < ActiveRecord::Base # nothing here end class StatisticsObserver < ActiveRecord::Observer observe Amodel #can you register more than one class per Observer or create a parent class for statistics? def after_create(obj) increment_counter(a) end def after_update(obj) update_counter(a) end end So the counter (i.e. the key) would simply be based upon the object attributes concatenated with some sort of time derivative. So we could track sunday orders above a certain value by month and hide all of that logic in the Observer. Then pulling the values of these counters should be easy for creating charts, reports and so forth. O. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
