Rails 2.3 Model.touch(:column) always also updates :updated_at???

Hi,

Am I the only one (i.e. something I do is wrong), or does the touch-
method always update updated_at, even though giving it a column to use
INSTEAD is meant to update just that column???

Thanks,

Michael

Hi,

Am I the only one (i.e. something I do is wrong), or does the touch-

method always update updated_at, even though giving it a column to use

INSTEAD is meant to update just that column???

Thanks,

Michael

Michael, is the attribute that you’re passing to the touch method a field of type datetime or date? If not, then it only makes

sense that field that you’re passing to the touch method is one of those.

Good luck,

-Conrad

Michael, is the attribute that you're passing to the touch method a field of
type datetime or date? If not, then it only makes
sense that field that you're passing to the touch method is one of those.

It is "datetime".

But anyway, just looking at the code for "touch" I can't see how it's
is supposed to NOT always write updated_at - it uses write_attribute
which as far as I found out only changes the in-memory object, there
must be a "save" somewhere else and that goe4s through the usual
validations etc. There's a lighthouse ticket for "touch" calling for
it not to do validations (https://rails.lighthouseapp.com/projects/
8994-ruby-on-rails/tickets/2520-patch-activerecordtouch-without-
validations).

In the mean time, can you work around this issue with something like:

Create a separate table with a 1:1 relationship to your current table
Migrate the field you want to touch to the new table.
Touch the field in that table, which will leave the updated_at field
in your original table alone.
You could even make the new table without the timestamps fields, if you wanted.

--wpd

Well, I'm using separate timestamps for associated objects as an aid
for cache-key generation, to avoid throwing out too many cache entries
needlessly. I could look at the updated_at of the associated items
themselves - but guess what, I want to save database queries :slight_smile: So
adding another table is not quite the way.
I consider writing my own (SQL-based!) method, especially after
finding out through the lighthouse ticket mentioned previously that
all the validations are called. I have quite a few triggers and
procedures in the database already anyway doing stuff behind rails'
back, I would just like to limit those to certain critical areas, and
a (non-frequent) timestamp update wasn't on my list of things to do
through trigger rather than through actvierecord.

Thanks,
Michael

...

Create a separate table with a 1:1 relationship to your current table

...

So... I put it all into the mySQL triggers now. Saves a lot of
ActiveRecord overhead anyway, and keeps this very low-level issue/
optimization away from the "business logic" of the application.