Welcome Guest, Not a member yet? Register   Sign In
Going from OBsession to CI 1.6.1
#1

[eluser]MadZad[/eluser]
I'm upgrading us from CI 1.5.4 to 1.6.1, and I expect we'll stop using OBsession in favor of the normal Session library. But I've run into a potential show-stopper.

OBsession allows you to specify a database (not just table) for storing session info, and that was critical for us. We have several apps on one CI installation, and each one uses its own DB. One of those apps is logon, so that contains all the user info (each user can access multiple apps) and was a natural place to put the session table. It looks like the CI native Session expects the session table to be in the application's db. True? If so, any ideas on how to approach this - always force session lookups from a specific DB?

Alternatively, have folk had success using OBsession with 1.6.1? For reference, I'm not interested in switching to Kohana.

Thanks for any feedback...

Gene
#2

[eluser]Derek Allard[/eluser]
Hey Gene. You are correct, the CI session implementation doesn't account for a separate database for session data. Truthfully, its not something that even really occurred to me. You can configure CI to use 2 different databases, but without spending some time combing code, I'm not sure offhand what would be involved with respects to changing things around.
#3

[eluser]johnwbaxter[/eluser]
I'm using obsession with ci 1.6.1. Works a treat.

Remember to copy over the extra config settings that obsession needs to the new ci though!

I must say i was very very very happy that upgrading went so well and with so little effort.
#4

[eluser]MadZad[/eluser]
Derek - I am not surprised. This does not sound like a feature that would get utilized by most folk. Besides, if this feature wasn't available initially, we could have designed our shared code/data differently.
Thank you for the very quick reply. A fast "no" is very valuable feedback, as it saved wasted searching/experimenting time. For reference, I added this to the "Feature Request" forum (http://ellislab.com/forums/viewthread/72630/) as we're going to opt for keeping OBsession instead of modifying the native Session for now.

audiopleb - Thank you very much for the quick reply as well. My initial tests with the same OBsession replacement library with CI 1.6.1 have all been successful. More testing will be necessary, but so far this is making for a happy Monday (until the coming snowstorm hits us).
#5

[eluser]Michael Wales[/eluser]
Your best bet - at getting this accomplished, is to add a new database connection to database.php and then making some enhancements to OBSession. My first attempt would be simply telling it to switch connections in the constructor/destructor. Not sure if it would work as easily as that as I've never used/looked at OBSession - but the logic is there...
#6

[eluser]MadZad[/eluser]
Michael,
Short answer
Actually, it's even easier than that. We do indeed define the shared database in application/config/database.php as you point out. OBsession allows you to specify the database within application/config/config.php via
Code:
$config['sess_database'] = 'my_shared_db';
Therefore, it will store session info the DB and table that you configure. No code alterations necessary.

Long-winded answer
First, little background specific to us that might be useful to other folk in this boat. Our applications essentially have 2 of each CI config file:
ci_home/application/config/config.php
ci_home/application/app_name/config/config.php
(and autoload.php, database.php, etc) The app_name config files are automatically picked up by CI, of course. Most of the time, that file consists of:
Code:
$shared_config = CI_APPLICATION_ROOT_FOLDER . "/config/" . basename(__FILE__);
if (file_exists($shared_config)) {
  include($shared_config);
}
else {
  exit("error - no shared config exists");
}
But if there is application-specific configuration necessary, it goes after that code. In the case of database.php, the shared config file defines $db['shared'] and the app_name config file defines $db['my_app_db']. The applications then know to access their own my_app_db for their stuff, and 'shared' to tap the shared (user/login) database. Note - we do not have a default database connection. To keep things clear, we always specify which database connection to use, and every application necessarily has 2 connections. Our code isn't as concise, but clearer for our purposes.

If the existing OBsession addition had not worked with CI 1.6, our next step would probably have been to try using CI 1.6's Session, and have our shared database be the true default database. I think this probably would have worked, since Session.php uses $this->CI->db for the db connection. We could let it think that our 'shared' db was the one, true connection - and the applications would have been responsible for using their own connection to reach their own DB.

This sounds like a similar mindset to your suggestion, but if the above attempt hadn't worked, I don't think it would have occurred to me to change the connections in the session class con/destructors - which now that you said it, sounds obvious. THAT might be an excellent approach for adding the "pick your DB" feature to CI's new Session library.

Thanks for your feedback!

Commentary:
Oscar did a very nice job with this addition (http://ellislab.com/forums/viewthread/49253/), and clearly had fun writing the documentation. We just happened to rely on a feature that didn't make it into CI 1.6 ... yet.
#7

[eluser]sholnay[/eluser]
[quote author="MadZad" date="1203741564"]I'm upgrading us from CI 1.5.4 to 1.6.1, and I expect we'll stop using OBsession in favor of the normal Session library.[/quote]

I've read this now in a few posts - that the 1.6.1 release has some updates to the session library? I checked the change log and didn't see any changes mentioned there for the last couple revisions. Are 3rd party libraries still the only way to store session data in the database? I have the default ci session handler running (and set to use the db) and while it is updating values (session_id, user_agent, etc) in the db - it isnt storing any userdata there.

Hope this isn't too off topic from the OP's question - I didn't think it required a whole thread of its own though.

Thanks!




Theme © iAndrew 2016 - Forum software by © MyBB