Rails Ruby on Rails → 3.0.2

Comments and changes to this ticket

• 

  Sam Ruby May 28th, 2009 @ 09:12 PM

  Attached is a patch to Rails that get the tests to pass again. Warning: it does so by effectively reverting this change.

  The test cases isn't minimal, but is relatively small. Setup should take less than a minute:

  git clone git://github.com/rubys/awdwr.git
  cd awdwr
  ruby makedepot.rb 6.1-7.4 save

  Once that is complete, the scenario itself can be repeated at will with the following:

  ruby makedepot.rb restore 8.1-8.5

  In both cases, replace with the path to your checkout of Rails.

  • 2734.diff 809 Bytes
• 

  Sam Ruby May 29th, 2009 @ 06:27 AM

  • Tag changed from “3.0, session” to “3.0, patch, session”
• 

  josh May 29th, 2009 @ 04:32 PM

  • Milestone cleared.
  • State changed from “new” to “open”

  I can't exactly tell how the failing example is setup. Can you setup a minimal case? Even better a unit test. It could be difficult if it is related to a reloading issue.

• 

  Sam Ruby May 29th, 2009 @ 04:46 PM

  I'm traveling at the moment, so it will be a few days before I try to create a more minimal test case; but it does look like lighthouse mangled my instructions.

  A more legible set of instructions can be found at the following places:

  http://intertwingly.net/blog/2009/05/15/Keeping-Up-With-Rails

  http://github.com/rubys/awdwr/raw/13d847d07cd0d8ff080d8163eb5e48cfb...

  Applied to this ticket, the easiest way to reproduce this is to run sections 6.1-7.4 using a checked out version of Rails and save the results; and then continue from the restore point with sections 8.1-8.5 to see the error.

  It doesn't appear to be a reloading issue, but clearly is a regression. My suggestion is that the change be backed out (or disabled) until it can be debugged.

• 

  Sam Ruby May 30th, 2009 @ 03:46 AM

  I've reviewed the code in question, and here is what I found: the commit in question optimizes out writing out sessions unless a direct assignment is made to the session object.

  In my case, the session contains a Cart object. The first request will cause the Cart to be added to the session. Subsequent requests won't directly assign to the session, but will update the cart object.

• 

  josh May 30th, 2009 @ 03:33 PM

  • State changed from “open” to “resolved”

  Thats a clear reason, reverting.

• 

  Jeremy Kemper October 15th, 2010 @ 11:01 PM

  • Milestone set to “3.0.2”
  • Importance changed from “” to “Medium”

  [bulk edit]