Re: [Pas-dev] more on generic DB session obj

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

Kyle R . Burton wrote:
>>Poking around the directory some more:
>>
>>- Org::Bgw::Pas::Session::MySQL becomes Org::Bgw::Pas::Session::DB.  _factory() 
>>method gets re-written to look up the driver from the config file and 
>>instantiate the appropriate DB factory driver for the session.
>>
>>- Then we create a new Org::Bgw::Pas::Session::Factory.  Stuff that can be moved 
>>from Org::Bgw::Pas::Session::MySQL::Factory will be moved into this new class.
>>
>>- The MySQL directory gets moved to a new name Factory.
>>
>>- Org::Bgw::Pas::Session::MySQL::Factory becomes 
>>Org::Bgw::Pas::Session::Factory::MySQL.  All generic stuff is striped so it's 
>>MySQL specific and it's parent becomes Org::Bgw::Pas::Session::Factory.
> 
> I like the idea of using a factory...but I don't want it to do a config lookup
> every time it creates a session object...perhaps we can cache it somewhere?
> Or am I just being paranoid?  Are the config lookups just as fast?  In fact,
> that might be what it's doing now...

Well, that's what it looks like it's doing for username, password, etc.

> I'm not yet set on what I think the cleanest/best design should be.  This 
> looks good at first glance.  I'm not necessarily convinced that what I wrote
> for the MySQL/Factory objets was a good appraoch to start with :)

Well, it might not have been the best approach to start with (I'm not completely 
sure without reviewing the other objects), but what has been proposed is easy to 
implement, won't really hurt anything and will allow plugins for different 
databases for the session.  If we want to restructure stuff at a later date, we 
won't be wasting much time with this improvement now.

>>- In the conf file we should add the driver to make it easy for the person to 
>>tell the app what DB they want to run for the session.  So you'll now have up to 
>>7 session variables for the config file:
>>
>>   pas.session.dbname
>>   pas.session.driver
>>   pas.session.dsn
>>   pas.session.hostname
>>   pas.session.password
>>   pas.session.table
>>   pas.session.username
> 
> 
> Maybe prefix these with pas.session.db.* to follow the convention?  We
> currently have pas.session.file.*, pas.session.apache.*, and 
> pas.session.mysql.*, so perhaps it should be pas.session.db.*?

Sure.  Sounds good.  I missed the other prefixes.

>>Of course, if you specify the dsn, you can skip the dbname & hostname.  The 
>>driver parameter will be a requirement!
> 
> The reason dsn is in there as a parameter is because it's actualy hard to
> dynamicly build a dsn depending on the driver and the options the user
> wants to pass. Maybe we should just forget the dbname, and hostname and
> expect the user to specify them in the dsn?

I understand the reason.  If we want to get rid of hostname & dbname, that 
simplifies things!

>>Any questions?  Does this sound good?  Can I take a chain saw to it?  I'll at 
>>least get this working for MySQL in the near future.  Other implementations 
>>shouldn't be hard.
> 
> It sounds good so far, I just want to talk about it some more until I feel
> comfortable about it.

It works well with the structure that's there.  To make the changes and have it 
up and running for MySQL will take less time then these conversations.  Then 
going forward for Oracle & PostgresSQL won't take much time either (we should 
just have to overriding 2 methods, insert & update).  Most of that time will be 
researching on how to deal with blobs.

Justin