[Mongrel] Recommentation: Sessions and PStore

Zed Shaw zedshaw at zedshaw.com
Mon Sep 4 14:32:44 EDT 2006

On Mon, 2006-09-04 at 17:02 +0200, Jacob Atzen wrote:
> On Sun, Sep 03, 2006 at 09:18:06AM -0700, Zed Shaw wrote:
> > 
> > This especially goes for you Java people who think the session store is
> > a temporary database.  The session really only works for simple types
> > like integers, strings, etc.  You *must* follow the mantra of "Share
> > Nothing" and either store everything in the database or use form fields
> > and GET parameters to make it stateless.  As I've said repeatedly, "If
> > rails-core don't do it, you don't do it."  Rails-core does not do this.
> > You don't do it.
> This piece of advice I find a little troubling. Often you have to store
> a lot of data temporarily in your application, f.ex. with multipage form
> submissions. Having to store only simple types will make this much more
> complicated compared to simply storing a single object in the session
> which is repeatedly updated until stored in the database.
> Is the data in the session not simply marshalled and then read back on
> the next request? If so, what is the difference between simple and
> complex types, they should marshal and unmarshal equally well, yes?
> Am I missing something here?

I generally do these things to work with large objects that are built in

1) Include a "state" variable that determines what stage of its
preparation it is currently at.  This gets saved and updated as you
operate making it possible to restore it to where it needs to continue.
Very handy in situations where people need to save their job and come
2) Store only the object id in the user's session, or better yet
associate the user with the object(s) being built and call that
association their "queue".  This lets them create and manage jobs as
3) Make the larger object composed of smaller object representing the
parts that make up your forms/stages.  This lets you put the validations
in the smaller objects and save them as the user goes, but then use a
large complete object later.
4) If you have to use one giganto object then find a way to either not
do validations or do them in a delayed fashion (this is a royal pain).
5) Finally, use Ajax in key places to make building and modifying the
smaller objects more seamless.

Staged forms are kind of an addiction in business process redesign, and
many times when you're forced to break the process down into smaller
data objects you begin to see a pattern that lets you redesign the
process to be simpler.  Many times what you think are discrete stages
are actually very similar.

But, if you've *got* to use a staged form process then really use the
state field to implement a state machine.  This gives you more error
correction capabilities and makes it easier to translate people's in
process work when the state machine changes.  You just run a migration
that moves everyone to the new required state, or zaps their in process
work (if that's possible).

Another thing you'll find is that this is faster than session storage
because AR (and many ORM) store only the deltas.  Since smaller data
chunks are getting saved between form views it tends to go quicker than
saving the whole massive blob to the session after marshaling.

Hope that helps.

Zed A. Shaw
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

More information about the Mongrel-users mailing list