Perl: Storing Cart-Like items in Mysql without CGI::Session
 

Hello,

Some time ago I was storing items through a quasi-login system in a MySQL table just being seperated with alternations of symbols (aka &item1:quantity:tag&item2:quantity:tag&) this seemed inefficient but worked and solved my needs for the time being. Later I got into another fun-filled project and created a proper pseudo-store with a cart and sessions. Using CGI::Session I was able to spit an 'Array of Hashes?' into the param and it handled it properly into MySql...

Example:

I would like to recreate an item-system as described above however by storing the array of hashes in the MySQL Table. Is anyone aware of a proper way to do this without the CGI::Session approach to where it handles grabbing this array of hashes? If not is there any suggestions?


Thanks!

Management of sessions through persistent data is a different and distinct concept from storing data in a backend database. The data used to maintain sessions must, by definition, be stored on the browser, as it is the unique element in the session. Do you have some objection to the use of CGI::Session? What 'Bad Thing' are you trying to solve by not using it?
--- rod.

What I was trying to describe is that I am using sessions, however for the previous system I was able to store the items through the Param function of CGI::Session -- This is not acceptable means through a login system as the items need to be continually stored rather than temporarily. This would be possible if perhaps I was to keep a side of permanent sessions however that seems like a non-proper and long way to solve a simple issue.

Basically I am looking for a way to store a dynamic number of items with different properties into a MySQL table tied to an individual and keep that information. I found the way above in the example suitable for handling it with Sessions as the Param function handles it properly, if I attempt so without the Param function into a normal column in MySQL (I believe) it just stores a hash or reference as it has been a few weeks since I attempted it.

I am not sure on exact proper terms for everything so I understand if what I am stating does not make much since.

I'm still not too sure what problem, exactly, you are trying to solve, but here's my interpretation. You have arbitrarily long and dynamic lists of items in shopping carts, and you want to maintain sessions associated with each list. Your session information can be used as a key for lookup of lists in the backend database. The only session-specific information maintained on the browser is the session key itself. Just attach a key value to the session, and store that key value in a field in the table(s) that contain the shopping cart data. Then, you can use that key value to lookup all data for each active cart. No item data storage needs to be done in the browser.

--- rod.

Let me try to explain this another way...

I am not trying to store the items with the browser. I have a MYSQL database.

The browser is storing sessions: 1, a typical shopping cart 2, a login system

The shopping cart is storing its items temporarily using CGI::SESSIONS->PARAM which stores the param's into the MYSQL under the SESSION DATA. The code tags on the first post describe how this is being done.

I want it so people with shopping cart, can login and store the items in a more permanent solution.

I am trying to find the best way to do this, as I am no longer going to be storing the items with CGI::SESSIONS the whole CGI:SESSION->PARAM is not going to work. I am trying to figure out how to store them into a MYSQL Table like CGI::SESSION->PARAM does or at least a suitable method that allows the same ease of flexibility.


I mean how would one normally go about storing a large number of dynamic items in MYSQL, would having the script creating a table of items for each user be better suited?

So, your question is simply how to store data into MySQL tables? In general, Perl DBI is the solution to that. As for how the database is organized, I don't think we have nearly enough knowledge of the application to make useful suggestions about that. Design of database applications is a very broad subject, and without a lot of specific understanding of your application, it will be difficult to give application specific advice. If you need advice on the use of Perl DBI, this is probably a good place to ask.
--- rod.