Rails core - Apr 2010 - [PATCH] Add :touch option to has_many associations

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.

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.

"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.

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.

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.

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.

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.

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.

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.

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.

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.