Re: DBIx::DBH - Perl extension for simplifying database connections
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
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
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