3.2.4 Regression: Model.all cache not invalidated on inserts #6576

Closed
iGEL opened this Issue May 31, 2012 · 5 comments

Projects

None yet

7 participants

@iGEL

Hi!

I believe I found a regression between 3.2.4.rc1 and 3.2.4.

If you call .all on a model, then change the database via AR and call .all again, the cache doesn't get invalidated and the old, unchanged state is returned. I tried the mysql2 and sqlite3 database adapter.

It's caused by this change: rails/rails@ac465d5

Before that change:

Loading development environment (Rails 3.2.4.rc1)
1.9.3-p194 :001 > Song.all
  Song Load (0.2ms)  SELECT "songs".* FROM "songs"
 => []
1.9.3-p194 :002 > Song.create name: "asdf"
   (0.1ms)  begin transaction
  SQL (45.4ms)  INSERT INTO "songs" ("album_id", "created_at", "name", "updated_at") VALUES (?, ?, ?, ?)  [["album_id", nil], ["created_at", Thu, 31 May 2012 20:27:32 UTC +00:00], ["name", "asdf"], ["updated_at", Thu, 31 May 2012 20:27:32 UTC +00:00]]
   (202.1ms)  commit transaction
 => #<Song id: 1, album_id: nil, name: "asdf", created_at: "2012-05-31 20:27:32", updated_at: "2012-05-31 20:27:32">
1.9.3-p194 :003 > Song.all
  Song Load (0.2ms)  SELECT "songs".* FROM "songs"
 => [#<Song id: 1, album_id: nil, name: "asdf", created_at: "2012-05-31 20:27:32", updated_at: "2012-05-31 20:27:32">]

After that commit:

Loading development environment (Rails 3.2.4.rc1)
1.9.3-p194 :001 > Song.all
  Song Load (0.1ms)  SELECT "songs".* FROM "songs" 
 => [] 
1.9.3-p194 :002 > Song.create name: "asdf"
   (0.1ms)  begin transaction
  SQL (45.3ms)  INSERT INTO "songs" ("album_id", "created_at", "name", "updated_at") VALUES (?, ?, ?, ?)  [["album_id", nil], ["created_at", Thu, 31 May 2012 20:29:21 UTC +00:00], ["name", "asdf"], ["updated_at", Thu, 31 May 2012 20:29:21 UTC +00:00]]
   (201.0ms)  commit transaction
 => #<Song id: 1, album_id: nil, name: "asdf", created_at: "2012-05-31 20:29:21", updated_at: "2012-05-31 20:29:21"> 
1.9.3-p194 :003 > Song.all
 => [] 

/cc @tenderlove

@techwhizbang

/cc @tenderlove @spastorino Indeed this is what I was reporting on Twitter earlier

@yaroslav

It seems that the same issue can be reproduced when calling ::last on a model.

@aderyabin

In continue of message from @yaroslav this gist displays problem with ::last https://gist.github.com/2846392

@tgildea

See this pull request for more info:

#6558

Here is a gist for a quick monkey patch
https://gist.github.com/2846496

@radar

I think this may be caused by @ac465d5.

@pixeltrix pixeltrix added a commit that referenced this issue Jun 1, 2012
@pixeltrix pixeltrix Restore behavior of Active Record 3.2.3 scopes
A series of commits relating to preloading and scopes caused a regression.
Cloning the relation calls initialize_copy which resets a number of instance
variables to nil. Without this the scope thinks that it is already loaded
when it is called again.

Reverts the following commits:
13f1401
8491740
dffbb52

Fixes #6575, #6576 & #6577
7056079
@jahnique jahnique pushed a commit to zweitag/spree that referenced this issue Dec 13, 2013
@radar radar Revert back to Rails 3.2.3
This is due to a number of regressions reported in Rails:

rails/rails#6576
rails/rails#6577

As well as a failing test inside of api brought on by rails/rails@ac465d5.

There is also the issue of link_to_function's deprecation in this version of Rails, which is still used in a couple of places in Spree.
593e451
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment