Hi all, I''ve been using rails for a little while and have an idea for an improvement to the counter cache. I''d like to run it by you guys first before I go ahead with a PR. As I understand it currently, the counter cache for a collection is only updated when a child is created or destroyed by incrementing or decrementing the count. I''d like to propose two changes: 1. Change the count update to happen when a child model is saved. This will allow the counter cache to keep up to date when a child object is moved from one parent to another. My idea for a basic implementation is to not necessarily to increment/decrement but to instead do a ''select count'' to get the correct count for the affected objects. 2. Following on from #1, when specifying the use of a counter cache allow the developer to supply a where clause that is used with the select count. This will allow counts based on state. For example, a count of number of active users within a company (rather than all users in a company). Based on the limited detail above, does this sound like something worth doing and if so what issues should I be aware of? This will be my first PR for rails so I need all the help I can get! Thanks in advance Andy -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Hello Andy, thanks for you your interesting in contributing to Rails, we''re very happy about that! :) Regarding your questions: 1) I think this has been implemented by this commit: https://github.com/rails/rails/commit/455d710242f24f0cfff89f626164493276e0f3e9, so we have one man down ;). 2) I''d be willing to give a +1 on that, I''ve already had this requirement before and I think it''s rather common. Others might have a different opinion though, so it might be good to wait for a little bit more of feedback before starting. Or you can also give it a try (if you''re willing to) and come up with some working code in a pull request as a first iteration, and we can discuss from there (at least some rough idea about how the API would work, like adding a proc to counter cache or something like that?) That''s it. Hope that helps, and see you soon in the contributors list ;) Cheers! On Tue, Apr 2, 2013 at 7:24 PM, Andy Pike <andy.pike.mail@gmail.com> wrote:> Hi all, > > I''ve been using rails for a little while and have an idea for an > improvement to the counter cache. I''d like to run it by you guys first > before I go ahead with a PR. > > As I understand it currently, the counter cache for a collection is only > updated when a child is created or destroyed by incrementing or > decrementing the count. I''d like to propose two changes: > > 1. Change the count update to happen when a child model is saved. This > will allow the counter cache to keep up to date when a child object is > moved from one parent to another. My idea for a basic implementation is to > not necessarily to increment/decrement but to instead do a ''select count'' > to get the correct count for the affected objects. > 2. Following on from #1, when specifying the use of a counter cache allow > the developer to supply a where clause that is used with the select count. > This will allow counts based on state. For example, a count of number of > active users within a company (rather than all users in a company). > > Based on the limited detail above, does this sound like something worth > doing and if so what issues should I be aware of? > > This will be my first PR for rails so I need all the help I can get! > > Thanks in advance > > Andy > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscribe@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- At. Carlos Antonio -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Also reviewing this gem may be of value in terms of considering changes to counter caches. https://github.com/bestvendor/counter_culture Cheers, Anthony On Wed, Apr 3, 2013 at 8:54 AM, Andy Pike <andy.pike.mail@gmail.com> wrote:> Hi all, > > I''ve been using rails for a little while and have an idea for an > improvement to the counter cache. I''d like to run it by you guys first > before I go ahead with a PR. > > As I understand it currently, the counter cache for a collection is only > updated when a child is created or destroyed by incrementing or > decrementing the count. I''d like to propose two changes: > > 1. Change the count update to happen when a child model is saved. This > will allow the counter cache to keep up to date when a child object is > moved from one parent to another. My idea for a basic implementation is to > not necessarily to increment/decrement but to instead do a ''select count'' > to get the correct count for the affected objects. > 2. Following on from #1, when specifying the use of a counter cache allow > the developer to supply a where clause that is used with the select count. > This will allow counts based on state. For example, a count of number of > active users within a company (rather than all users in a company). > > Based on the limited detail above, does this sound like something worth > doing and if so what issues should I be aware of? > > This will be my first PR for rails so I need all the help I can get! > > Thanks in advance > > Andy > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscribe@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Thanks for the feedback guys. Yes, I was thinking about adding an optional proc to the counter_cache call which can hold the predicate. So without it, counter_cache just operates as it does today but if it''s given a proc then it will use this when counting. I''m happy to give it a try, the rails code base is a little daunting but I''m up for the challenge. I''ll take some time to research and will probably bug you guys here with silly questions if that''s ok ;o) Cheers Andy On Wednesday, 3 April 2013 03:20:33 UTC+1, Richo99 wrote:> > Also reviewing this gem may be of value in terms of considering changes to > counter caches. > > https://github.com/bestvendor/counter_culture > > Cheers, > > Anthony > > On Wed, Apr 3, 2013 at 8:54 AM, Andy Pike <andy.pi...@gmail.com<javascript:> > > wrote: > >> Hi all, >> >> I''ve been using rails for a little while and have an idea for an >> improvement to the counter cache. I''d like to run it by you guys first >> before I go ahead with a PR. >> >> As I understand it currently, the counter cache for a collection is only >> updated when a child is created or destroyed by incrementing or >> decrementing the count. I''d like to propose two changes: >> >> 1. Change the count update to happen when a child model is saved. This >> will allow the counter cache to keep up to date when a child object is >> moved from one parent to another. My idea for a basic implementation is to >> not necessarily to increment/decrement but to instead do a ''select count'' >> to get the correct count for the affected objects. >> 2. Following on from #1, when specifying the use of a counter cache allow >> the developer to supply a where clause that is used with the select count. >> This will allow counts based on state. For example, a count of number of >> active users within a company (rather than all users in a company). >> >> Based on the limited detail above, does this sound like something worth >> doing and if so what issues should I be aware of? >> >> This will be my first PR for rails so I need all the help I can get! >> >> Thanks in advance >> >> Andy >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rubyonrails-co...@googlegroups.com <javascript:>. >> To post to this group, send email to rubyonra...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.