Re: Subclassing DBI - architecture question

2003-12-11 Thread Tim Bunce
 $dsn = $name_to_dsn_hash{$dsn} unless $dsn =~ /^dbi:/i;

Tim.

On Thu, Dec 11, 2003 at 12:08:19PM -0500, Chuck Fox wrote:
> Hello fellow coders,
> 
> I have successfully subclassed DBI with the intent of overridding the 
> connect method so that I can retrieve the password from my password 
> server.  One of my primary considerations in subclassing DBI was to not 
> change the interface.  However, one of my co-workers is insisting that 
> we modify the interface so that a RDBMS's name be passed separately.  My 
> point back to him was that there are RDBMS's that do not have a name but 
> rather an address (host:port).
> 
> My question is: Do I attempt to parse the DSN for the name of the 
> server, or force my users to pass it separately ?  I am heavily leaning 
> to the former as this allows a very seamless transitition to the new 
> module.  However, I am loathe to investigate and write/lift parsing code 
> for each DBD I want to support.
> 
> Here's where you come in and say, "Good idea Chuck, but"
> 
> TIA,
> 
> Chuck
> 


Subclassing DBI - architecture question

2003-12-11 Thread Chuck Fox
Hello fellow coders,

I have successfully subclassed DBI with the intent of overridding the 
connect method so that I can retrieve the password from my password 
server.  One of my primary considerations in subclassing DBI was to not 
change the interface.  However, one of my co-workers is insisting that 
we modify the interface so that a RDBMS's name be passed separately.  My 
point back to him was that there are RDBMS's that do not have a name but 
rather an address (host:port).

My question is: Do I attempt to parse the DSN for the name of the 
server, or force my users to pass it separately ?  I am heavily leaning 
to the former as this allows a very seamless transitition to the new 
module.  However, I am loathe to investigate and write/lift parsing code 
for each DBD I want to support.

Here's where you come in and say, "Good idea Chuck, but"

TIA,

Chuck