I'm currently developing a laravel app and want to implement Laravel Shopping Cart in it. But before I do so, I have one question: As I figured out, all shopping card information is stored in the session. If I know log out/close browser/etc., my session is gone, so is the shopping cart.
How can I store shopping cart information in db and restore it, when needed? And: when do i save it in db? and when do I get it out again?
File based session or database based session both will destroy on logout,close browser etc.
You need to create 2 tables in your database
table_shopping_cart => id, session_id, user_id, created_at, updated_at, invoice_id etc
table_shopping_cart_items => id, cart_id, item_name, item_qty, price etc
And you can run scheduler or cron query with specific date/time to delete expire entries from both table.
I would say storing the information is a database is a little bit of overkill if it is not a business rule. People often save carts during a shopping spree online and adding the complexity of a data layer at this point sounds like its a little out of scope for this question.
If you were to save it, the cart would need to be associated with a particular login. If that infrastructure already exists then saving their information in a database will be easier.
What type of database are you using?
Related
I'm developing a shopping cart for a website, and was wondering what way should I store the product id after the user has clicked on the "Add to cart".
Should I store them in a session -- Such as
$_SESSION['cart'][$productid]++;
Would this put strain on the server under load? Or is this the best way of doing it?
Or should I create a temp database table, store the information in there, and remove after order has been processed?
I would store them in a database for sure, but not create a temp table each time. I would suggest you keep a table that has all the unfinished orders along with an identifier for the user.
This will last longer than a session, all it to be retained after a user has logged off and available after that user logs back in again. When then user is logged in, keep their identifier in the session.
Edit: While connecting to a database does consume resources, that is what database servers are made for. A connection to a small table uses next to nothing - I mean, you are probably executing a good number of queries just displaying your shopping cart. If you get to the point where your website can't handle the extra stress due to saving an odd row in a small table, you will be getting enough money from the sales to buy a bigger server :)
You should definitely use a database table to store the items.
Logged-in users will appreciate that they didn't have to grab all items again, if they come back after some time!
You can keep the information of the cart in the session, to get the information you need, but you should set new information in the session and in the database!
And then before checkout you should cross-check your information.
Another advantage is that you can keep track of what is going on in your shop!
You wont have any information if no one buys your items and you store the carts in a session.
I figure that this should be possible, as it is a requirement asked by my supervisor. There are a few types of accounts, one of them is a 'company' account which should allow anyone in the company who has these credentials to log in at the same time.
Now my question is, how do I store temporary data like:
(this is fictive)
shopping carts, keeping track of wizards,...
I suppose that I'll have to store this in the database?
What would be my best option. Link it to the unique session id?
Yes, you can store sessions in your database if you like. A nice way to do it, is by creating a sessions like table that stores states. Therefore, if you have a cart, you can have a cart table that represents what products the cart has and replay that after a user logs back in.
Session information isn't based on your account-system but on the system of the visitor (cookie). Unless you want all information to be shared across all users logged in on the company account (which I doubt) you shouldn't have to store any of the information in the database.
To store the data you can simply keep using session (as I suppose you already do for the 'normal' account.
I'm using CodeIgniter's Session class to manage my sessions for a cart/checkout system. The session data is being stored in the database and the session id is stored in a cookie. All cart information is retrieved via AJAX and is kept in the session, along with the session id.
Right now I am using the session id that PHP/CodeIgniter generates as a way to keep track of users. Users do not log in to the site and the store and the cart/checkout system are on different domains so this is the only thing that is tying them to their cart that is stored in the session/database. I use this session id in hidden fields on forms and as a parameter in links so that it gets sent to the server on any request (add item, remove item, view cart, etc...)
CodeIgniter lets you set a time for regenerating the session id, right now I have it set to 10 minutes. I had it at the default but that was too short because if the user sat at the page for too long, the session id that was dynamically written to the links and forms would be out of date and no longer tied to their cart data.
This is obviously not a great solution. What is the best way to allow for regenerating session ids at a lower interval but still keep users tied to their cart data even if the user waits 10+ minutes (without a page refresh) to do an action?
Don't use the session id's in the database. The cart should persist across sessions, so you need to store the cart in relation to the user, not the session. I also would not be putting the session id in fields as a hidden field. The benefit of sessions is you can store them server side.
Store the cart in the database, don't load the whole thing into session.
Method #1
A user can be given an "active" cart in the database.
User -> (has many) Cart
This cart is then updated by adding items to it
/cart/add/{id} -> Verify prices / quantities
This cart is not linked to the session, the session is only controlling which user is logged in. When they checkout the cart is set from "active" to "ordered" and a new "active" (but empty) cart is created. Carts will persist in the database between sessions, and a full history can be made available.
Method #2
Store the entire cart in session, not backed against the database. This would make some things simpler (adding / removing items aren't DB operations) but it also won't persist across sessions. When a user checks out write the cart to the database.
I am coding a E-commerce website/admin interface for a client. They are doing some B2B so they want the cart to be saved/loaded from database so if the user close his browser and reopen it the cart is intact.
The application is using the Zend Framework and I've been looking to the Zend_Session_SaveHandler_DbTable. So I can save the session in the database easily what about the reverse case I want to load the database in session.
Also it would be nice if can load that cart items only when the users reopen the browser not on every page since it would have some performance impact.
Any advices ?
Kind of sub question: I suppose Zend_Session is using $_SESSION so everything is based on the php session id, is there any possibilities to change what it is using has id.
I am thinking of generating my unique id and pushing this to client with cookies.
NOTE 2: the user is able to build some cart not being logged so I cannot rely on the login process ....
The first thing you need to do is work out how to make sessions persist beyond the user closing their browser. Check the Zend_Session configuration part of the manual:
http://framework.zend.com/manual/en/zend.session.global_session_management.html
see the part on the 'remember_me_seconds' option. Once you have this working, anything you store in the session will be available when the user comes back another day.
As for storing the cart in the session, I would suggest creating a 'Cart' class which contains this information. You could then either store the whole object in the session or store the data in a 'carts' table in your database and merely store the ID of the cart in the user's session. Then on subsequent visits you just have to check for the existence of the ID and load the Cart up if it's present.
I had same problem as you when I wanted to store column settings for grid before two weaks.
And I didnt have whole session in DB. I just check session if there is something in the cart. If there is nohing in session, load from db. And on every change of basket save to db of course.
And I used serialized array from Session_Namespace::to_array() method. not whole Session_Namespace because of I cant load it back.
You can use flag which eill tell you, that you try load from db once, for instance that there is no cart in db same in session and you dont want try to load cart every request.
I am in the process of making a website that involves a shopping cart.
There are two major requirements:
The user experience guys want login/authentication to be the very last step in the entire work flow. The user gets to do all the shopping and is asked to login only at the time of checking out.
The shopping cart shouldn't expire(not even on browser close) unless the user (registered or not) does check-out.
In the above context, I have the following question with respect to maintaining the cart's state:
Should I go with file based or database sessions? Please keep in mind this would be for unregistered users. My apprehension is that I'll end up having lots of records in the database.
Another option seems to be to put the cart contents in an encrypted cookie, but then there's a size limitation on the cookie file.
What would you do in this case ? I would really appreciate your answers.
Tracking a user. Use a GUID
encoded into a cookie with an
nYear expiry.
Storing a Shopping Bag. You don't want to store the bag in the cookie, mainly due its possible size. This leaves the option of persiting it to a medium and retrieving it from the medium. Using anything except a database for this would be like going back in time, databases excel at storing and retrieving data.
Managing you Shopping Bag. Now, the
question of your schema, firstly, if
your going to be running queries
against the shopping bags in the
database (i.e. how many shopping
bags contain item x) you probably
want a traditional relational
schema. However this has overheads
in terms of inserting. updating,
selecting (and joining) and deleting
bag data (at some point you'll have
bags that will never be used again
but are taking up precious disk
space). With a busy site, this is a
fair few Traranactions Per Second,
but any database should be able to
cope. If you don't need to query
the shopping bags in the database,
then you can store it as XML. Just
serialize the bag and dump it into a
table, with the PK as the GUID as
stored in the users cookie. This
would be a lot faster than a
traditional schema, plus you could
always tear apart the XML in the
future if a requirment did come up
for a relational schema.
This is what we do (Xml Bag), and we have a million+ customer base.
I would go with database managed sessions over file managed sessions. Make sure you have a session timestamp so that you can eventually kill old sessions (if it's been 12 months, the shopper is possibly not coming back for the items originally in the cart).
Doing this with a database instead of files will make it easier to eventually expire the very-old information.
Note that the database session will only ever be valid as long as the cookie it's tied to on the user's computer. If the user comes back to the store from a different browser, they will not find their session. If two people are sharing the same computer, they will find each other's session. Hopefully no potentially embarrassing items will be in the cart...
Store in cookies the AnonymousSessionID, with which you associate a shopping cart in the database.
Then you'll have a scheduler task to erase anonymous sessions after some time (say, a day). This will keep your database clean of abandoned sessions.
If a user registers, you reassociate their shopping cart with their account permanently. If the users makes an order, you empty their shopping cart.
If you're using ASP.NET here's what I'm (about) to do:
use a Profile to capture the users email as soon as possible (to email them if they dont complete the order). you can enable anonymous profile properties that are persisted to the aspnet database even if the user hasnt actually truly registered.
stick an XML bag representing an order into session. This is persisted in the database with a regular identity ID.
store the ID of the cart in the ASP.NET Profile. that way when the session expires you can just reload it from the ID in the profile. this has the benefit that the user never sees the cart ID in a cookie and you can easily link records between the membership/profile database and the store you're using for your orders
(dont try to store the XML order in the Profile. i think thats asking for performance issues. but in theory you could i suppose)
With those specs I would go with a database based session state. But you should do some heavy reading on how session state is handled in your web server of choice. Since you want to be able to revive the state to the correct person.
I think you have some expectations to manage, or maybe you weren't clear on requirements.
The user experience guys want login/authentication to be the very
last step in the entire work flow. The
user gets to do all the shopping and
is asked to login only at the time of
checking out.
The shopping cart shouldn't expire(not even on browser close)
unless the user (registered or not)
does check-out.
Specifically, an anonymous, not logged-in user's cart being saved? That's madness. Ensure that's not an expectation and clarify it in your design documents.