On 1 Dec 2008, at 02:15, adamc wrote:
> > Hi, > > I've started looking at the counter_cache implementation with the > original intention to have the increment, decrement update the model > in memory (without relying on a reload) to be called. > Be aware of the subtleties involved if someone else has also created a record (which is why the counter code doesn't just do foo.bars_counter += 1; foo.save) Fred > You can see a sample of the bug here: http://gist.github.com/30580. > > While starting to look at this issue (my first real look at the rails > code base) I'm wondering if anyone has already done any initial > thinking of this issue or has an idea of what they would like to see > happen here. In my initial thinking (I haven't looked at the > association proxy/collection enough) there could be a bi-directional > link for the has_many/belongs_to reflections/assocations. > > Looking around I noticed a small bug with custom counter cache names > not be utilized in the record with the has_many association. There is > currently no way for this association/reflection object to know about > the belongs_to settings where the counter_cache name is set. > > An easy way to quickly solve this is to add a :counter_cache => > 'custom_name' to the has_many method call. What are your thoughts on > this proposed change for the has_many options? > > Thanks, > Adam > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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-core?hl=en -~----------~----~----~----~------~----~------~--~---
