Re: DBIx::DBH - Perl extension for simplifying database connections

2004-12-02 Thread Mark Stosberg
On Wed, Dec 01, 2004 at 06:39:00PM +, Tim Bunce wrote:
 
 FWIW, the reason I'm digging here is because I agree there may be
 some value in the DBI supporting something along these lines, but
 I need a better understanding of the underlying issues. More real-
 world examples would help.

I agree solving this in DBI is ideal. DBI is about abstraction, 
and this is one commonly used bit that varies from database to database. 

 It'll always come down to the issue of why not store complete DSNs?
 and so far that's not been well covered by the feedback I've got.

I've always stored each piece as as separate config variable. Maybe it's
because that's the way my brain works. I don't think what's the DSN?,
I think What's the username? the port number? the host name?. 

I like for the software to work how I think, rather than bending my head
around the format that's easiest for the computer. 

Mark


Re: DBIx::DBH - Perl extension for simplifying database connections

2004-12-02 Thread Henri Asseily
On Dec 1, 2004, at 10:39 AM, Tim Bunce wrote:
On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote:
On Wed, 1 Dec 2004 09:46:24 +, Tim Bunce [EMAIL PROTECTED] 
wrote:
Do you generally pass URLs around as a string or broken up into a 
hash?
If they had different formats for different consumers, I would.  (And 
even
today, I use my own URI objects when I know I'll have to do any 
significant
amount of manipulation.)

I think this module is definitely useful.  I already store my DSNs in 
hashes
and assemble the pieces as necessary depending on the driver.
Lots of people do, it seems, but I'm not getting much background about 
why.

FWIW, the reason I'm digging here is because I agree there may be
some value in the DBI supporting something along these lines, but
I need a better understanding of the underlying issues. More real-
world examples would help.
It'll always come down to the issue of why not store complete DSNs?
and so far that's not been well covered by the feedback I've got.
Tim.
I have to agree with Tim. In my DBIx::HA module that manages 
high-availability and has multiple data sources per database handle, 
here's how the config looks like:

$DATABASE::conf{'my_db'} = {
   max_retries = 2,
   db_stack = [ #format: dsn, username, password
 [ 'dbi:Sybase:server=;database=A', 'user', 
'pass' ]
 [ 'dbi:Oracle:server=;database=B', 'u1', 'p1' ]
 [ 'dbi:Pg:host=aaa;port=1212', 'u2', 'p2' ]
   ]
   connectoninit   = 0,
   pingtimeout = -1,
   connecttimeout  = 3,
   executetimeout  = 20,
   callback_function = \Travolta::callback_HA,
   failoverlevel = 'application',
};

The DSNs are so different, and allow for so much choice, that it's just 
as easy to fully qualify them.
For example, the Sybase DSN can take hostname=, scriptname=, etc...

H


Re: DBIx::DBH - Perl extension for simplifying database connections

2004-12-02 Thread Henri Asseily
On Dec 1, 2004, at 10:39 AM, Tim Bunce wrote:
On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote:
On Wed, 1 Dec 2004 09:46:24 +, Tim Bunce [EMAIL PROTECTED] 
wrote:
Do you generally pass URLs around as a string or broken up into a 
hash?
If they had different formats for different consumers, I would.  (And 
even
today, I use my own URI objects when I know I'll have to do any 
significant
amount of manipulation.)

I think this module is definitely useful.  I already store my DSNs in 
hashes
and assemble the pieces as necessary depending on the driver.
Lots of people do, it seems, but I'm not getting much background about 
why.

FWIW, the reason I'm digging here is because I agree there may be
some value in the DBI supporting something along these lines, but
I need a better understanding of the underlying issues. More real-
world examples would help.
It'll always come down to the issue of why not store complete DSNs?
and so far that's not been well covered by the feedback I've got.
Tim.
I have to agree with Tim. In my DBIx::HA module that manages 
high-availability and has multiple data sources per database handle, 
here's how the config looks like:

$DATABASE::conf{'my_db'} = {
   max_retries = 2,
   db_stack = [ #format: dsn, username, password
 [ 'dbi:Sybase:server=;database=A', 'user', 
'pass' ]
 [ 'dbi:Oracle:server=;database=B', 'u1', 'p1' ]
 [ 'dbi:Pg:host=aaa;port=1212', 'u2', 'p2' ]
   ]
   connectoninit   = 0,
   pingtimeout = -1,
   connecttimeout  = 3,
   executetimeout  = 20,
   callback_function = \Travolta::callback_HA,
   failoverlevel = 'application',
};

The DSNs are so different, and allow for so much choice, that it's just 
as easy to fully qualify them.
For example, the Sybase DSN can take hostname=, scriptname=, etc...

H