Re: [Pas-dev] Support for other DBs in the session

[Justin B. <ju...@le...>]

>>>Yes, and in your config file, you specify what child of these classes to
>>>use, correct? So you'd be setting
>>>pas.session.object=Org::Bgw::Pas::Session::Db::Pg or something right?
>>
>>Pretty much.  Every so slightly different.  Org::Bgw::Pas::Session::DB 
>>determines the correct object to use by what's in the config file.  Right now 
>>it's reading the variable pas.session.db.driver from the config file.
> 
> A parent knowing about its children strikes me as bad. Shouldnt the
> config file tell pas what session object to use for sessions? Then pas
> instantiates a session of type N and uses it.

Org::Bgw::Pas::Session::DB isn't a parent object, it's an implementation of the 
session interface with a factory method to create the object for the DB backend 
and then delegates to it.  Like I said in a previous discussion, the name can be 
a little confusing.

So, naming convention aside, I believe it does what you're talking about.

>>So you pas.session.object will only be valid for the following session types: 
>>File, DB or Apache.  So if you set pas.session.object to DB, the 
>>pas.session.db.driver tells the application what kind of DB the session will be 
>>connecting to.
> 
> I think we need 2 settings in the config, DB type (file, apache, rdb)
> and session type so that we use the right loader/storer stuff.

We have that.  pas.session.object is for the session type and 
pas.session.db.driver determines the right DB to use.

>>>>Small modifications to Org::Bgw::Pas::Session::DB and a new class of 
>>>>Org::Bgw::Pas::Session::DB::mysql was all that was needed.
>>>>
>>>>And I guess I should write some unit tests before commiting.  ;)  I'd also like 
>>>>to commit the Postgresql implementation at the same time.  I have to remember 
>>>>how to configure Postgresql.
>>>
>>>Actually, its not hard. And since its new, it doesnt matter. Just make
>>>sure you dont break mysql and commit what you have. I have postgres
>>>setup and can test/tweak and write tests for that piece if you want. Or
>>>I can create you an account on hades and you can do stuff there. 
>>
>>What I meant by configuring is setting up users and then setting passwords & 
>>privileges.  It's been too long since I've used Postgresql.  It's just a matter 
>>of finding the right page in the manual.  I've created a user, a database and 
>>the pas_session table.  I'm not sure if I have a password or the privileges 
>>right yet.  I may also need to upgrade to 7.1 or 7.2 (I'm running 7.0.3 right now).
> 
> That really depends. YOu can configure it so that anything that connects
> to the local box is trusted. This is independent of tcp connections. Its
> all in the user/admin guide. vi /etc/postgresql/pg_hba.conf 

I wanted it to connect just like MySQL with a user name and password.  I didn't 
want to do a trusted user.  Like I said, it's been a while but I found it.  I 
now have an instance of PAS working with Postgresql 7.0.3.  I'm sure if my 
session gets large enough (>8k?) I'll crash it unless I upgrade to at least 7.1.

>>>The way I see this working is that we simply provide a way to get
>>>sessions working in the app. I dont see the DB layer ever doing anything
>>>more. Then developers can write their own page object in pas/pages (or
>>>wherever) that connects to their X database. They would derive from this
>>>OtherDatabase class for their other page objects. This is probably the
>>>most non-invasive/easist way to go. Sessions and other data dont even
>>>need to be in the same db at that point. Forgive me if I'm stating the
>>>obvious, but we may want to add some note to this effect in our docs if
>>>there isnt one already. 
>>
>>I guess if we want to go this way, we'd need to change the config file parameter 
>>to something closer to what you suggested.  Then people can add the different DB 
>>  session classes outside the Org::Bgw namespace.
> 
> Why do they need to use our config file at all? And what would prevent
> them from adding an entry and using it as things stand now?

They don't have to use our config file.  They'd have to set these parameter in 
their own config file if they want it to work tho.  What prevents them from 
adding an entry and using it as things stand now is that the session is tied to 
either type: File, Apache or Mysql.  There is no option to use Postgresql or 
Oracle to store the session in a DB.  After my mods, they won't be tied down.

>>But I also think it would be good if we could provide support for as many 
>>databases as possible (session & other wise).  Then at least we can sound kewl 
>>and can word salad people with large lists!!
> 
> So should we have an Org::Bgw::Pas::Db object that you can use to get a
> generic_dbh? 
 >
> What if you have 5 different data sources? I think we should make it
> easy to extend after we get the session stuff sorted out. 

Probably, but I think you're going beyond the scope of this modification.  ;)

Justin