At 08:53 PM 12/6/2009, you wrote: >(F) a visitor enters the site, a session is started, the cart_id is >added to the session, items are added to the cart. Now the visitor >logs in and becomes a @user. Let's add the cart_id to the @user >object and save the @user. The user leaves the site, comes back >after a long period (let's say 30 hours). Meanwhile, a session >sweeper has deleted "stale" sessions included our @user's. He comes >back to the site, there is no session record, so he's no longer >logged in and so the connection to the cart_id is lost. From the >user perspective (and the Rails perspective), there is no cart right >now. A new session is created. The user has a choice right now: >- logs in and gets his previous cart restored (does he know he can do that?) >- starts creating a new cart >- logs in -- oh, oh, now what? Do we use the new cart? the old cart? >merge the two? >- since the user assumed the old cart was gone, IMO, you ignore the >old cart and use the new one.
This is like the case I first hit that let me know there was a problem. "Cookie, cookie, cookie...." >Another option -- Two separate cookies! Let the session system >handle its own cookie like normal. *Don't* store the cart_id in the >session. *Don't* store the cart_id in the user record. Instead, >create a second independent cookie that is not tied to the >expiration of the session. Store the cart_id in this new cart >cookie. Use cookie expiration attributes to have that cookie last as >long as you want (7 days, 30 days, "forever"). Now, no matter when >the user comes back, or whether the user was ever logged in or not, >the old cart will still be available--as long as you match your cart >sweeping to complement the expiration timing of the cookie. But this is an interesting idea, give the cart its own cookie so it can expire on a different schedule from the session. "Cookies....cookies...." Thanks! Scott -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
