Hi guys, I was in discussion with Nicolaas about this topic before it was posted here. We've been thinking about the way the SilverStripe eCommerce cart could work in future. The system was originally built to store the cart data in the session, then save it to the database. Ultimately we want to reduce the core code to only what is necessary.
Can anyone comment any specific security risks storing form data in the session, as opposed to in the database if you are doing multi-step forms for example? @Neven: Could 'not needing to clean up the database' be such a benefit? But to clean up may be as little as a few lines of code run every so often. I also agree with Nick, that stored info could be useful to analyse. Regarding speed - I'm guessing there could be little noticeable difference using session or database, particularly with the average order/cart size being so small. On the other hand if there is a lot of activity on the site, session could be faster...as I think simon is suggesting. Can anyone comment on this? Jeremy On Jul 15, 6:44 pm, nicolaas <[email protected]> wrote: > Hi Folk > > Are there any arguments for or against the use of session for saving > cart information before committing it to a database (usually at the > moment of sale confirmation)? > > For: > * less database clutter > * faster? > > Against: > * more code > * less information on potential sales is retained in database > > Other things to consider are: > * can save some stuff, but not all > * security / privacy matters > * database maintenance / clean up procedures > * length of session > * ?????? > > I am welcoming any comments, for and against, just curious to know if > there are any "best practices" in this area. -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
