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 have created a ticket with a patch attached: https://rails.lighthouseapp.com/projects/8994/tickets/4392-add-touch-option-to-has_many-associations <https://rails.lighthouseapp.com/projects/8994/tickets/4392-add-touch-option-to-has_many-associations> cheers -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
"Diego Carrion" <dc.rec1@gmail.com> wrote in message news:m2pc455cfa11004151155x9d1affb0r1bfcbb4de166b240@mail.gmail.com... Hi,>it would be nice to have the touch option in has_many associations also.It exists in belongs_to already, right? Does it also already exist in has_one? If not it would be odd to have it in has_many but not in has_one. If has_many has :touch, then has_and_belongs_to_many should also get :touch too, no? There it is thankfully equivlent if you thing of this thouch as belonging to either the has_ or belongs_ side of said relationship. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Diego Carrion
2010-Apr-17 23:55 UTC
Re: Re: [PATCH] Add :touch option to has_many associations
Yes, it exists in belongs_to already. It doesn''t exists in has_one. I added the option to has_many because I really needed it, I prefer to add functionalities on demand. If you think it will be useful to implement the option in has_one and has_and_belongs_to_many associations, I can do it without problems :) On Sat, Apr 17, 2010 at 6:04 PM, Joe Smith <unknown_kev_cat@hotmail.com>wrote:> > "Diego Carrion" <dc.rec1@gmail.com> wrote in message > news:m2pc455cfa11004151155x9d1affb0r1bfcbb4de166b240@mail.gmail.com... > > Hi, > > it would be nice to have the touch option in has_many associations also. >> > > It exists in belongs_to already, right? > > Does it also already exist in has_one? If not it would be odd to have it in > has_many but not in has_one. > > If has_many has :touch, then has_and_belongs_to_many should also get :touch > too, no? There it is thankfully equivlent if you thing of this thouch as > belonging to either the has_ or belongs_ side of said relationship. > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Joe Smith
2010-Apr-18 23:32 UTC
Re: Re: [PATCH] Add :touch option to has_many associations
"Diego Carrion" <dc.rec1@gmail.com> wrote in message news:p2pc455cfa11004171655l1300ccaehd146e09577f6b6f6@mail.gmail.com...>Yes, it exists in belongs_to already. > >It doesn''t exists in has_one. > >I added the option to has_many because I really needed it, I prefer to add > >functionalities on demand.Adding functionality on demand is a great way to write applications. It is the basis of TDD and BDD. But it does not work quite as well for frameworks in my opinion. For a framework to work well it should be consistant. I should be able to guess functionaility based on what I already know, rather than having to look it up. Rails generally does quite well with that.>If you think it will be useful to implement the option in has_one and > >has_and_belongs_to_many associations, I can do it without problems :)I would like it, but I am a nobody, just a regular rails user, so don''t assume my stances are shared by the core team. My thoughts are that here it would be inconsistant to not implement it on all 3 has_* associations. My gut tells me that there is nothing special about the has_many case that would justify only it having this feature. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Prem Sichanugrist
2010-Apr-18 23:36 UTC
Re: Re: Re: [PATCH] Add :touch option to has_many associations
Agree with that. If has_many has :touch option, it would be great to all of has_* to have that functionality too. Diego, could you submit a patch for this? :) - Prem S. On 19 เม.ย. 2553, at 6:32, Joe Smith wrote:> > "Diego Carrion" <dc.rec1@gmail.com> wrote in message news:p2pc455cfa11004171655l1300ccaehd146e09577f6b6f6@mail.gmail.com... >> Yes, it exists in belongs_to already. >> >> It doesn''t exists in has_one. >> >> I added the option to has_many because I really needed it, I prefer to add >functionalities on demand. > > Adding functionality on demand is a great way to write applications. It is the basis of TDD and BDD. But it does not work quite as well for frameworks in my opinion. > > For a framework to work well it should be consistant. I should be able to guess functionaility based on what I already know, rather than having to look it up. Rails generally does quite well with that. > >> If you think it will be useful to implement the option in has_one and >has_and_belongs_to_many associations, I can do it without problems :) > > I would like it, but I am a nobody, just a regular rails user, so don''t assume my stances are shared by the core team. > > My thoughts are that here it would be inconsistant to not implement it on all 3 has_* associations. My gut tells me that there is nothing special about the has_many case that would justify only it having this feature. > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Diego Carrion
2010-Apr-19 00:46 UTC
Re: Re: Re: [PATCH] Add :touch option to has_many associations
Thans for the feedback, I added the touch support to has_one associations also. 2010/4/18 Prem Sichanugrist <sikandsak@gmail.com>> Agree with that. If has_many has :touch option, it would be great to all of > has_* to have that functionality too. > > Diego, could you submit a patch for this? :) > > - Prem S. > On 19 เม.ย. 2553, at 6:32, Joe Smith wrote: > > > > > "Diego Carrion" <dc.rec1@gmail.com> wrote in message > news:p2pc455cfa11004171655l1300ccaehd146e09577f6b6f6@mail.gmail.com... > >> Yes, it exists in belongs_to already. > >> > >> It doesn''t exists in has_one. > >> > >> I added the option to has_many because I really needed it, I prefer to > add >functionalities on demand. > > > > Adding functionality on demand is a great way to write applications. It > is the basis of TDD and BDD. But it does not work quite as well for > frameworks in my opinion. > > > > For a framework to work well it should be consistant. I should be able to > guess functionaility based on what I already know, rather than having to > look it up. Rails generally does quite well with that. > > > >> If you think it will be useful to implement the option in has_one and > >has_and_belongs_to_many associations, I can do it without problems :) > > > > I would like it, but I am a nobody, just a regular rails user, so don''t > assume my stances are shared by the core team. > > > > My thoughts are that here it would be inconsistant to not implement it on > all 3 has_* associations. My gut tells me that there is nothing special > about the has_many case that would justify only it having this feature. > > > > -- > > 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Michael Koziarski
2010-Apr-19 03:00 UTC
Re: [PATCH] Add :touch option to has_many associations
On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Diego Carrion
2010-Apr-19 04:34 UTC
Re: [PATCH] Add :touch option to has_many associations
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 <michael@koziarski.com>wrote:> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <dc.rec1@gmail.com> 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 <michael@koziarski.com> > wrote: >> >> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper
2010-Apr-19 21:01 UTC
Re: [PATCH] Add :touch option to has_many associations
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 <pratiknaik@gmail.com> 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 <dc.rec1@gmail.com> 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 <michael@koziarski.com> >> wrote: >>> >>> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> 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 rubyonrails-core@googlegroups.com. >>> To unsubscribe from this group, send email to >>> rubyonrails-core+unsubscribe@googlegroups.com. >>> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Diego Carrion
2010-Apr-19 21:16 UTC
Re: [PATCH] Add :touch option to has_many associations
Ok, what about the has_one association? cheers On Mon, Apr 19, 2010 at 6:01 PM, Jeremy Kemper <jeremy@bitsweat.net> 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 <pratiknaik@gmail.com> 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 <dc.rec1@gmail.com> > 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 < > michael@koziarski.com> > >> wrote: > >>> > >>> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> > 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 rubyonrails-core@googlegroups.com > . > >>> To unsubscribe from this group, send email to > >>> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > >>> 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 rubyonrails-core@googlegroups.com. > >> To unsubscribe from this group, send email to > >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > >> 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Michael Koziarski
2010-Apr-19 23:05 UTC
Re: [PATCH] Add :touch option to has_many associations
the has_one case makes sense, sure. On Tue, Apr 20, 2010 at 9:16 AM, Diego Carrion <dc.rec1@gmail.com> wrote:> Ok, what about the has_one association? > cheers > On Mon, Apr 19, 2010 at 6:01 PM, Jeremy Kemper <jeremy@bitsweat.net> 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 <pratiknaik@gmail.com> 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 <dc.rec1@gmail.com> >> > 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 >> >> <michael@koziarski.com> >> >> wrote: >> >>> >> >>> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> >> >>> 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 >> >>> rubyonrails-core@googlegroups.com. >> >>> To unsubscribe from this group, send email to >> >>> rubyonrails-core+unsubscribe@googlegroups.com. >> >>> 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 rubyonrails-core@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> rubyonrails-core+unsubscribe@googlegroups.com. >> >> 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 rubyonrails-core@googlegroups.com. >> > To unsubscribe from this group, send email to >> > rubyonrails-core+unsubscribe@googlegroups.com. >> > 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Diego Carrion
2010-Apr-19 23:23 UTC
Re: [PATCH] Add :touch option to has_many associations
Hi Michael, I''ll send the patch with this modification only, thanks. cheers On Mon, Apr 19, 2010 at 8:05 PM, Michael Koziarski <michael@koziarski.com>wrote:> the has_one case makes sense, sure. > > On Tue, Apr 20, 2010 at 9:16 AM, Diego Carrion <dc.rec1@gmail.com> wrote: > > Ok, what about the has_one association? > > cheers > > On Mon, Apr 19, 2010 at 6:01 PM, Jeremy Kemper <jeremy@bitsweat.net> > 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 <pratiknaik@gmail.com> 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 <dc.rec1@gmail.com> > >> > 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 > >> >> <michael@koziarski.com> > >> >> wrote: > >> >>> > >> >>> On Fri, Apr 16, 2010 at 6:55 AM, Diego Carrion <dc.rec1@gmail.com> > >> >>> 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 > >> >>> rubyonrails-core@googlegroups.com. > >> >>> To unsubscribe from this group, send email to > >> >>> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > >> >>> 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 > rubyonrails-core@googlegroups.com. > >> >> To unsubscribe from this group, send email to > >> >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > >> >> 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 > rubyonrails-core@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > >> > 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 rubyonrails-core@googlegroups.com. > >> To unsubscribe from this group, send email to > >> rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > >> 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 rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com> > . > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Seemingly Similar Threads
- Add shorthand support for routes like /projects/status(.:format)
- [PATCH] Rails 3: fields_for helper doesn't work with association proxy objects
- Filter Ordering in Edge Rails (Rev 7143)
- Polymorphic URL helpers documentation and fixes
- A little love for acts_as_taggable #8279