the has_one case makes sense, sure. On Tue, Apr 20, 2010 at 9:16 AM, Diego Carrion <[email protected]> wrote: > 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]. >> >>> 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. >> > >> > >> >> -- >> 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. >
-- 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.
