Accessing multi-level arrays stored in Sessions

[eluser]ckeller[/eluser]
I'm in the process of converting an existing app where I stored the session data for a user in this form: $_SESSION['user'][attribute1], $_SESSION['user'][attribute2], etc, in other words, all the user info is stored in the 'user' array in the session.

The problem is, I want to then be able to check for the existence of a value in that user array but there is no way to access that specific $_SESSION['user']['userToken'] item directly through the CI Session library.

I actually had to write a function that takes the 2 parameters and returns the value I want or false if it does not exist.

Am I missing something? Is there a way to store an array in the session and check for a specific value in that array?

(I'm just getting started, thanks).

Chris

[eluser]jedd[/eluser]
[quote author="ckeller" date="1248800226"] ... in other words, all the user info is stored in the 'user' array in the session.[/quote]

Can I ask why? It seems to me that session data is entirely about the user, so why the indirection?

The problem is, I want to then be able to check for the existence of a value in that user array but there is no way to access that specific $_SESSION['user']['userToken'] item directly through the CI Session library.

Correct - you'd have to write a helper or something in MY_Controller if you want to have your function pervasively available.

Have you considered just pulling session data out of the 2D array?

[eluser]ckeller[/eluser]
The reason I do things this way is because I do have other data stored in the session pertinent to the app sometimes. However, I also want the flexibility to either reload the entire user array from the user table (such as if they logged in), and if I ever needed to unset just that user info, I could just unset that array and not lose what else is in the other session variables.

What did you mean with this question? "Have you considered just pulling session data out of the 2D array?"

Thanks.

[eluser]jedd[/eluser]
[quote author="ckeller" date="1248807746"]The reason I do things this way is because I do have other data stored in the session pertinent to the app sometimes.[/quote]

Well, in general, stuff in session data should be dependent on the user - otherwise it's a bit of a waste.

Can you give some examples of stuff that's unrelated to the user, but tied to the app only?

However, I also want the flexibility to either reload the entire user array from the user table (such as if they logged in), and if I ever needed to unset just that user info, I could just unset that array and not lose what else is in the other session variables.

You mean you serialise $_SESSION['user'] and store that in the database?

So any time a user changes a configuration setting, it doesn't update the database until they log out, and even then it only updates the internals of a single large array rather than a column in a table - is that what you're saying?

WRT 'unset just that user info' - what other user's info exists in that user's session, can I ask?

What did you mean with this question? "Have you considered just pulling session data out of the 2D array?"

I mean adopt a flatter approach to the session data. Rather than $_SESSION['user']['is_admin'] - just use $_SESSION['is_admin'], for example.

[eluser]ckeller[/eluser]
It's basically just another way of namespacing those variables from the user record (the column names) in the session var and knowing you won't stupidly overwrite them. I think I'm just going to have to flatten them out or keep using the function I've been using. Thanks.

[eluser]jedd[/eluser]
Chris, I think flattening them out is going to work out better for you in the long run. I used to try to put some kind of hierarchy around this kind of data, but slowly moved away from that - it's just too expensive on so many levels, particularly once you start thinking in RDBMS terms. Sure, if you've got hundreds of data to play with, then it makes sense to force some structure around it - but for the kind of stuff that we tend to end up throwing into session data, it just adds more confusion than it's worth I think.