Ok, what about the has_one association? cheers
On Mon, Apr 19, 2010 at 6:01 PM, Jeremy Kemper <[email protected]> wrote: > Ditto. Using touch actually obscures the intent of your code. > > Touch means set updated_at timestamp, that's all. Not "re-evaluate all > children." > > -1 > > jeremy > > On Mon, Apr 19, 2010 at 1:59 PM, Pratik <[email protected]> wrote: > > 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]<rubyonrails-core%[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]<rubyonrails-core%[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]<rubyonrails-core%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > > > -- > 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]<rubyonrails-core%[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.
