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

rubyonrails-talk
1

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

2

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

3

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 (Dashboard - rails 8994-ruby-on-rails/tickets/2520-patch-activerecordtouch-without- validations).

4

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

5

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

...

6

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.