`:touch` option should only touch an associated record once per transaction

[bricker]

Consider these two models:

class Post < ActiveRecord::Base
  has_many :assets
end

class Asset < ActiveRecord::Base
  belongs_to :post, touch: true
end

If I go into a post and add, for example, 20 assets, this results in 40 extra queries to the database - 20 to select the associated Post, and 20 to "touch" the associated Post. Is this the desired behavior?

I think it's especially important to consider this now that the Rails framework is really advocating the use of the :touch with cache digests.

A shortened example from the logs: You can see how this could get ridiculous.

SQL (0.3ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, 'Asset #1')
Post Load (0.3ms)  SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 35401 LIMIT 1
SQL (0.3ms)  UPDATE `posts` SET `updated_at` = '2013-01-04 12:00:36' WHERE `posts`.`id` = 35401

SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, 'Asset #2')
Post Load (0.4ms)  SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 35401 LIMIT 1
SQL (0.3ms)  UPDATE `posts` SET `updated_at` = '2013-01-04 12:00:36' WHERE `posts`.`id` = 35401

SQL (0.3ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, 'Asset #3')
Post Load (0.3ms)  SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 35401 LIMIT 1
SQL (0.3ms)  UPDATE `posts` SET `updated_at` = '2013-01-04 12:00:36' WHERE `posts`.`id` = 35401

SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, 'Asset #4')
Post Load (0.4ms)  SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 35401 LIMIT 1
SQL (8.0ms)  UPDATE `posts` SET `updated_at` = '2013-01-04 12:00:36' WHERE `posts`.`id` = 35401

SQL (1.8ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, 'Asset #5')
Post Load (0.5ms)  SELECT `posts`.* FROM `posts` WHERE `posts`.`id` = 35401 LIMIT 1
SQL (0.4ms)  UPDATE `posts` SET `updated_at` = '2013-01-04 12:00:36' WHERE `posts`.`id` = 35401

To get around this, I've removed all :touch options and added a very simple callback which utilizes the somewhat-odd behavior that a model's callbacks get run even if the record isn't actually going to be updated:

class Post < ActiveRecord::Base
  has_many :assets
  after_save -> { self.touch }
end

class Asset < ActiveRecord::Base
  belongs_to :post
end

This ensures that the record will be updated no matter what, which is fine for my purposes, but feels like a hack. It also has the incidental benefit that anybody can manually expire a cache (i.e., bump the timestamp) by just saving the record (instead of having to add a hidden space somewhere to force the record's timestamp to update).

It results in a much cleaner log, with only ONE extra query, no matter how many assets you are saving:

SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, "Asset #1")
SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, "Asset #2")
SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, "Asset #3")
SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, "Asset #4")
SQL (0.4ms)  INSERT INTO `assets` (`post_id`, `caption`) VALUES (35401, "Asset #5")
SQL (0.3ms)  UPDATE `posts` SET `updated_at` = '2013-01-04 12:34:38' WHERE `posts`.`id` = 35401

So I guess the real issue is all those extra queries that get generated when using the touch option on belongs_to associations. It seems like it shouldn't be that way, but I'm not sure.

Thanks.

[PikachuEXE]

It's not really belongs_to problem
Its the touch option cannot detect whether the opposite side is has_many or has_one

[rafaelfranca]

Have you tried use the :inverse_of option?

[jeremy]

@bricker - agreed. It's by design, but it's a limitation. We'd like to accumulate all touches and apply them once in a before_commit callback. See f9da785#commitcomment-2370489 for more.

[SirRawlins]

Yeah - this little niggle has been causing me some challenges today, you've unable to use :touch in a Russian Doll style approach as it results in a huge number of callbacks up the object tree when in fact you only need a few.

[thomasfedb]

Agree with @bricker on this one. By design or not it's sufficiently bad behaviour to be considered a bug.

[kaspth]

@thomasfedb, @arthurnn fixed that for Rails 5: https://github.com/rails/rails/blob/52f90044a159559d94b4f597e9d79b44024ed09a/activerecord/lib/active_record/touch_later.rb 😉

[thomasfedb]

@kaspth is it documented anywhere? Can't find anything.

[kaspth]

Not sure. The original PR is here: #19324

[gingerlime]

I'm still trying to wrap my head around the best way to deal with this in a many-to-many scenario. e.g.

class Club
  has_many :members, through: :memberships
end

class Member
  has_many :clubs, through: :memberships
end

If I want an update to either member or club to touch all the relationships, I think the only viable way to do this is by using the (private?) before_commit callback, and then this avoids circular updates... Using after_save or after_touch seems to create a huge list of endless updates, until I reach Stack level too deep.

Am I missing something here? or is it really best to rely on the private before_commit hook in this case? Or maybe there's a different way entirely to handle this?

class Club
  has_many :members, through: :memberships
  before_commit -> { members.each(&:touch) }
end

class Member
  has_many :clubs, through: :memberships
  before_commit -> { clubs.each(&:touch) }
end