CI Session problem

[eluser]Akinzekeel[/eluser]
The session library renews the session_id in the database regularly for security reasons. That's fine, but how to I keep track of what is connected to that session in the database?

For example, I have a table "cart" with fk_session and fk_article which is basically my own cart library. It works fine for a limited time, but as soon as the session_id changes, the user will lose all articles in his cart because fk_session won't match anymore.

Using userdata() doesn't seem applicable since SQL WHERE and JOIN clauses won't work with serialized strings afaik.

So should I just disable session renewing or is there a better approach to solving this?

(Using CI 2.0, but older versions would be affected as well)

[eluser]WanWizard[/eluser]
The issue isn't really the session, but appearantly the way you have implemented your cart library.

A session ID is an internal value, which shouldn't concern you. CI takes care of this, and makes the session available to the application. All your library has to do is use it.

[eluser]Akinzekeel[/eluser]
Thanks for your answer, but I can't really make a solution out of it.

Can you please go into further detail on this? Which ID should I use instead?

I guess there's just something very simple that I'm failing to see :/

[eluser]WanWizard[/eluser]
You don't need an ID. The session is just there. I don't get why you would need an ID.

Have you read the User Guide, in particular the section on how to use the session library?

[eluser]Akinzekeel[/eluser]
I need the ID because every visitor (=session) must have its own independent cart. Without the session id, visitor A will see whatever visitor B will put in his cart and vice versa.

In the CI guide I did not find any information about my particular problem. And the builtin cart library does require the session library, but there is no technical information on how the cart data is stored. It's probably using the sessions' userdata(), however I need to to several JOINs so as mentioned in my initial post, this is not suitable for me.

[eluser]WanWizard[/eluser]
It sounds to me that your cart solution works completely independent of the session, and you 'borrow' the session ID to make your solution have a unique key.
Then make up your own unique cart ID, and store that in the regular session. As long as the session exists, that key stays the same.

I have a feeling you have made it overly complex.

The idea of a cart is that you store the ordered or selected items. In that case you don't need queries, all data you need is already in the cart datastructure.
If you absolutely need data external to the session data, store only the keys and use them to run the queries to retrieve extra information.

The relation between userdata, SQL statements, and 'serialized' is unclear to me. There is nothing serialized in the session?

[eluser]InsiteFX[/eluser]
Like WanWizard stated above!

Also if your users are logining in you could use the users login ID!

InsiteFX

[eluser]Akinzekeel[/eluser]
[quote author="InsiteFX" date="1286880096"]Also if your users are logining in you could use the users login ID![/quote]

This is how I did it in my previous project. But this time guests should be able to use a shopping cart as well.

I basically did what Wan suggested, in my cart constructor I always check if there is a cart_token in the userdata() array. If not, one will be generated. This cart_token is then used to identify which cart articles belong to which visitor.

I'm still not sure if you even understood my problem (sorry if I couldn't explain it very well) but for me the problem is now solved by generating my own ID instead of using the session ID.

[eluser]WanWizard[/eluser]
I understood your problem perfectly. You store your carts in a area (database, whatever) separate from the session storage. Which creates the problem of having no link to the user/guest's session.

And my point was: if you had stored the cart contents in the session in the first place, you would not have had this problem, and the need for a complex solution.

I still see no reason why you were not able to use the obvious solution to this problem.

[eluser]Akinzekeel[/eluser]
OK I see where this is going and I also realize that I caused the problem myself (D'oh!).

For performance reasons I usually change the userdata field from TEXT to VARCHAR because then the table engine can be set to MEMORY instead of MyISAM (MEMORY does not allow TEXT). According to the profiler, the session query is about 3 times as fast with a MEMORY table (may be marginal anyway, but hey, I take what I can get ^^).

What I, however, misunderstood, is that TEXT is in fact 65535 characters in length and not 255 (that would be SMALLTEXT). So I was always worried to save a lot of things in userdata() because 255 characters really isn't a lot to hold cart data, especially when serialize() and UTF-8 are used...

I think I somehow mixed up MySQL with MS Access data types, because in MS Access TEXT is (up to) 255 characters