addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

RE: [ruby-81] Sessions & Rails 2.3.2...

From: Jon S.
Sent on: Thursday, August 27, 2009 6:08 AM
Thanks Brendon... VERY helpful!
In my case, I use the before/after_save and after_find methods to encrypt/decrypt my data... not quite the same as your case as these are supposed to be user-installable callback hooks. The approach I used was modeled after the example in the AWDwithRails book (2nd edition - with better encryption, of course). I don't modify any of the core methods myself, but I wonder if one of my other plugins does or if they use these callbacks themselves... I'll dig into the code and see what's going on there.
I'm still curious as to why development mode works and production doesn't, but for now I'll settle for fixing what I've got :)

From: [address removed] [mailto:[address removed]] On Behalf Of Brendon Whateley
Sent: Wednesday, August 26,[masked]:35 PM
To: [address removed]
Subject: Re: [ruby-81] Sessions & Rails 2.3.2...

OK, I was curious as to what was happening, so I looked at the Rails startup.  I now know what was going wrong. 

During startup, Rails internals and ActiveRecord in particular does a lot of trick stuff with method aliasing.  If you redefine any (some?) of the aliased methods, the redefine takes place after the alias magic has taken place, this leaves your code running, but all the code that got aliased in gets disconnected.  The answer, obviously, is to add your method to the alias_method chain...

Basically, the message is if anything redefines any of the ActiveRecord internals, you have to be very careful that you don't lose side-effects that you need. This also means you need to do a fair amount of digging to discover why some of this stuff breaks.

When I first replied, I'd hoped it would be more useful!


On Wed, Aug 26, 2009 at 4:08 PM, Brendon Whateley <[address removed]> wrote:
Having spent the best part of a week debugging the sudden failure of sessions recently, I may be able to help.  The first thing to figure out is if the session is saving state and not loading, or loading but not saving.  In my case the ActiveRecordStore was not serializing the session data, but was loading and saving the session object.  This meant that previously set session values still existed, but any changes did not persist across calls.  I was able to validate that the logins were successful, but suffered similar issues to you.

In the end I tracked the problem down to overriding the ActiveRecord::Base.create_or_update method.  For some reason it completely broke ActiveSessionStore serialization, even if the redefined method contained the exact same code as the original.  I never completely figured out WHY that broke, but if I moved my changes to create and update methods that create_or_update called, I no longer experienced that problem.

My conclusion is that that code experiences some brittleness, most probably related to the filters.  If your code (or any gems/plugins) mess with any ActiveRecord methods, that would be where I'd start looking.

The other thing to think about would be going to SQLstore instead, which would make the session store a lot quicker.

Hope that is at least a little helpful,

On Wed, Aug 26, 2009 at 9:30 AM, Jon Seidel <[address removed]> wrote:
Hi... I've got a problem upgrading from Rails 1.3.6 to 2.3.2 and friends.
I use the session to store a couple of small but critical pieces of information for my app; I use ActiveRecordStore for this.

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Brendon Whateley ([address removed]) from The East Bay Ruby Meetup Group.
To learn more about Brendon Whateley, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy