I think I understand most of what you're trying to do, I just don't understand the need to store the account_id in the session table. In my opinion, it would be easier to store the account_id in the session itself (not a new column in the session table) and create another table which would store the account_id and session_id values (with as many session_id entries per account_id as you need) so you could lookup the sessions associated with the account without having to get into the session data itself (except, of course, for getting the account_id from the current session).
Honestly, every time I think of some idea for modifying the session table, I eventually run into something that requires replacing the write() method on the driver or something even more drastic.
To address some specific items in your text above:
Quote:I have a MY_Session:Confusedess_regenerate() function, which just stores the "old" session in a public property, executes parent:Confusedess_regenerate(), then stores the "new" session in a public property. Then whenever the Account_model finally loads, it will check if the $new and $old are both populated, if so, then that means the session was regenerated, so take all the "activity" (NOT in the ci_sessions table) and change the session ID to the $new session id, thus allowing the user to see the activity that was going on for the same Login, even though it was a different session.
I think something just clicked for me here, but I'm not going to go back and change what I wrote above. It seems to me that the "activity" should be associated with the account, rather than the session. The relationships in the database should tie to the activities to the account, not to the session. It's best to leave the session alone to do its work and leave it out of your database relationships (and that also frees you up to use a different session driver).
If you want to record the session_id used for an activity as some sort of artifact for logging or whatever, that's your prerogative. If you want that session_id to reflect the chain of regenerated session_id values, then create a new table with an auto ID value and a session_id value, record the auto ID in your activity table and update the new table's session_id when the session is regenerated. Then you just join the activity table to the new table and read the session_id from the new table, but the activities themselves are still related to the account by the account_id, and you display activities based on the account_id, not the session_id.
