Best performace/practice for storing temp data

Working on shopping cart app and stuck between storing shipping info in a db shipTable or in client scope.  I'm hesitant to store shipping info into the db because some users might not complete the transaction and take up rows in the db. On the other hand if I store shipping info in the client scope I'm not sure if this would impact the server. The goal is hold the users shipping info and later display/process the data on the final checkout page.  I tried using form variables but that only works from template to template. Any suggestions or opinions would be greatly appreciated. Thanks in advance.

You can use the session scope. You can copy the form vars to the session scope using structappend like so: <cfset  structappend(session, form, "true")> Or create another struct and store that in the session scope. <cfset StrctNew() = session.myvars> <cfset  structappend(session.myvars, form, "true")> Or something of that nature. I don't know if this is best practices... HTH G ----- Excess quoted text cut - see Original Post for more -----

> Working on shopping cart app and stuck between storing shipping info in a db shipTable or > in client scope.  I'm hesitant to store shipping info into the db because some users might > not complete the transaction and take up rows in the db.  On the other hand if I store > shipping info in the client scope I'm not sure if this would impact the server. Since Client variables are also typically stored in the database, I wouldn't worry too much about "taking up rows". I would also not recommend using both the Session and the Client scopes - use one or the other. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

What Dave said about client scope and db rows. For my own cart I wound up using client variables.  I felt they were more survivable than session vars.  Restart CF and lose your session vars... bad news on a shared server where the host might have an uneven record of uptime.  A cvar-based solution will typically survive a cf restart (user visits page, cf gets restarted while user reads content, next page hit is after restart and cvar cart contents persist). I haven't kept up with CF8's features but I believe they are in a struct now and much easier to work with as a result. My thinking behind not using a db table was that I would need to clean it up somehow, and the fact that the client variable db was automatically cleaned out over time (imperfect assumption on my part) did that job for me. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com

>My thinking behind not using a db table was that I would need to clean >it up somehow, and the fact that the client variable db was >automatically cleaned out over time (imperfect assumption on my part) >did that job for me. There are a lot of advantages to using the database and as a shopping cart becomes more and more complex, those become even more apparent. For instance, if your client decides at some point to track abandoned carts, this is far more easily done if that data is available directly from the database. It's a pretty simple function to just create a scheduled task that will clear out your cart tables on a regular basis, using a time stamp when you create the records to find the old ones. For my ecommerce product, pretty much everything is stored in the database, and then I just use a session variable with the cart ID, which also is saved to the user cookies and to the user table for logged in users as well. I also save a cart summary (items/total) to the session so I can display this on each page without recalculating the entire cart (which can be a LOT of calculation with a complex ecommerce app like mine). This gives you a pretty good persistent cart, with a very minimal amount of stuff needing to be kept in the session and/or cookies. So a lot depends on how simple you intend the cart to be, and the likelihood of it becoming more complex over time. ---- Mary Jo Sminkey maryjo@dogpatchsw.com Author of CFWebstore, CF-based E-commerce http://www.cfwebstore.com

Oops, just noticed the OP was specifically asking about shipping information. Personally, I generally use the session since if for any reason the CF server gets rebooted and it gets lost, the user is going to need to start the checkout process over again regardless. I do save their address information to a temp table, again, so it is available if I want to view that information on the merchant end, but otherwise I don't tend to use something like client scope for things like this that I don't need to persist for any length of time. But either will certainly work fine. ---- Mary Jo Sminkey maryjo@dogpatchsw.com Author of CFWebstore, CF-based E-commerce http://www.cfwebstore.com

I think a struct in a session is so much easier first you dont have to worry about cleaning up the database after the uses has finished or if the user drops out you dont have to create tasks to find redundancy data. you can have just as much hassle storing temp data in a database as in a session.... yes sessions can time out and you could restart the  cf application but the database stuff would be unless if that happened also as there is then nothing to match the user with the database data!!! you then have to start scheduling daily, weekly or monthly tasks to delete redundancy data.  

Whatever you do, don't take ease of programming your solution as a valid way to look at the problem.  You are talking about a cart checkout process.  The payoff to your client's entire business model. Paramount is making something that will not step on its own you-know-what ... ever.  As in fault tolerant.  I'd cross session vars clean off the consideration list since they can go byebye for a variety of common causes.  In my mind, we are talking about database or client vars.  Only.  Pick the solution that survives the most number of common, imperfect circumstances. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com

I'm leaning towards storing temp data in the client scope. Thanks guys for your valuable input and insight.