Agree with what Koz said. This isn't needed very frequently and it's easier to just use a before/after save callback if/when it's needed.
On Mon, Apr 19, 2010 at 5:34 AM, Diego Carrion <[email protected]> wrote: > Hi Michael, > in my case, an user gets only updated when he puts more money in his account > or when some of his money is taken because one of his advertises was > clicked. In this moment, all his advertises must be reevaluated to determine > if they're enabled or not. > I agree with you I can add the behavior with one line but it's less elegant. > I thinks this is the reason the belongs_to associations gained the touch > option. > I also agree with you this can lead to a bad performance in the application > but a lot of things in the Rails framework can lead to a bad performance, > too. If a developer is coherent it will use the Rails api > with responsibility. If a developer isn't coherent, I think he will have a > bad performance anyway, using Rails api or not. > Beside of that, I think we should worry with performance in the right time. > With a clean design, it will be easier to fix the problems when they appear. > cheers > > > > On Mon, Apr 19, 2010 at 12:00 AM, Michael Koziarski <[email protected]> > wrote: >> >> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <[email protected]> wrote: >> > Hi, >> > it would be nice to have the touch option in has_many associations also. >> > I have a scenario like this: >> > An user has some credit (money) and some advertises. Each advertise can >> > be >> > enabled or disabled depending on some rules. One of the rules is that >> > the >> > user should have money. Each time the money of the user change, the >> > advertises are touched, enabled/disabled and then cached, as they are >> > much >> > more requested that updated. >> >> I'm a little concerned that adding :touch to has_many and friends is >> encouraging bad practice (and terrible performance) when there's >> almost certainly a more performant solution available. It seems risky >> to me to allow a single option on association to cause every instance >> to be instantiated, changed, and written back to the database. >> >> In your particular case couldn't your cache keys include the >> updated_at value from a user? Alternatively you can get the >> behaviour you want with a 1 line after_save function without too much >> hassle? >> >> Is there a use-case I'm missing here? >> >> -- >> Cheers >> >> Koz >> >> -- >> 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. >> > > > > -- > Diego Carrion > http://www.diegocarrion.com > http://www.mouseoverstudio.com/blog/ > http://www.twitter.com/dcrec1 > http://www.workingwithrails.com/person/13580-diego-carrion > > -- > 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. > -- http://m.onkey.org | http://twitter.com/lifo -- 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.
