# Alternative to storing ActiveRecord object in session **URL:** \ **Category:** Rails\ **Created:** [June 13, 2008, 2:13am UTC](https://www.ruby-forum.com/t/alternative-to-storing-activerecord-object-in-session/140340 "2008-06-13T02:13:05Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Eric\_LIn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/45deac/32.png) [@Eric\_LIn](https://www.ruby-forum.com/u/Eric_LIn)\ **Post date:** [June 13, 2008, 2:13am UTC](https://www.ruby-forum.com/t/alternative-to-storing-activerecord-object-in-session/140340/1 "2008-06-13T02:13:05Z")
I’m writing a wizard-like module in my application where, in a series of steps, the user builds upon an ActiveRecord object, and in the end, saves the AR object into the database. The ActiveRecord object is fairly complex, with a has\_many association that could potentially get large, so I don’t want to store it directly in the session. In fact, having done so already caused a “marshalling data too short” error in my production server. Since the common wisdom is to never store AR object in session, what would you guys suggest as a way of storing temporary objects in the database, but make sure it’s deleted if user prematurely terminates the session? Thanks, Eric ---
**Author:** ![Eric\_LIn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/45deac/32.png) [@Eric\_LIn](https://www.ruby-forum.com/u/Eric_LIn)\ **Post date:** [June 13, 2008, 2:58am UTC](https://www.ruby-forum.com/t/alternative-to-storing-activerecord-object-in-session/140340/2 "2008-06-13T02:58:10Z")
On Jun 12, 2008, at 5:12 PM, Eric LIn wrote: > I’m writing a wizard-like module in my application where, in a series > of steps, the user builds upon an ActiveRecord object, and in the end, > saves the AR object into the database. The ActiveRecord object is > fairly complex, with a has\_many association that could potentially get > large, so I don’t want to store it directly in the session. In fact, > having done so already caused a “marshalling data too short” error in > my production server. Since the common wisdom is to never store AR > object in session, what would you guys suggest as a way of storing > temporary objects in the database, but make sure it’s deleted if user > prematurely terminates the session? I’ve built gajillions of these over the years (to where I finally abstracted the whole process to minimize what I had to write each time). Anyway, I learned two things: a) make the first\* step the definition of the user’s account and password b) store everything to the database as you go - “First step” – there’s some legitimate gripes for making the very first step of a signup process require a name & password. Depending on how it is done, it can seem overly agressive. So, by all means take into account your application and your audience and use a warm up page, but generally, don’t bother to start collecting loads of data until your user has committed to at least providing info to create an account. I generally ask for just the Name & Password and almost nothing else. If you need address & contact info, collect that later. That’s the part that makes most people stop & think when it’s the very first thing you ask for, so wait until they’re further along the commitment process. Doing this allows your user to bail and come back later without losing anything. It also enables your application to start storing to the database right away which is much easier to work with. You can send a welcome email right away with info on how to finish the process, and you can send a reminder or two if the signup is incomplete. It also gives you valuable data to see where in the signup process that people stop. Then you can start to ask “why do 40% of people stop and never come back after I ask for their height & weight?” So, how do you delete abandoned signups? Well, first, you need determine the criteria for abandoned. A user might legitimately come back two weeks later to finish after an interruption. You’ll know those guidelines for your own application. You might want to allow yourself many weeks before you delete records so you can see if there’s a window of time that people do come back. You mighht find that waiting 3 weeks catached 67% of abandoned users, but 6 weeks only 72%. So don’t be in a hurry to erase incomplete signups because it’s 4 hours old or something. There’s a lot to be learned from incomplete data. – gw ---
**Author:** ![Eric\_LIn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/45deac/32.png) [@Eric\_LIn](https://www.ruby-forum.com/u/Eric_LIn)\ **Post date:** [June 13, 2008, 6:11pm UTC](https://www.ruby-forum.com/t/alternative-to-storing-activerecord-object-in-session/140340/3 "2008-06-13T18:11:32Z")
Thanks. Although my application doesn’t deal with username and password, your suggestions do give me some ideas. ---
**Author:** ![Eric\_LIn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/45deac/32.png) [@Eric\_LIn](https://www.ruby-forum.com/u/Eric_LIn)\ **Post date:** [June 14, 2008, 1:49am UTC](https://www.ruby-forum.com/t/alternative-to-storing-activerecord-object-in-session/140340/4 "2008-06-14T01:49:29Z")
What I ended up doing was added an “in\_progress” flag to the ActiveRecord model, and persist the AR object on the first step. This way, if user stops in the middle, the “in\_progress” object will not be confused with objects that have gone through the process completely. And if the user restarts the process, the previous “in\_progress” object will be destroyed, freeing myself the duty of cleaning up stale objects periodically. Eric