Re: DBIx::DBH - Perl extension for simplifying database connections
From: Eric (ef_at_kwinternet.com)
Date: 12/01/04
- Next message: Ron Savage: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- Previous message: Tim Bunce: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- In reply to: Tim Bunce: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- Next in thread: Ron Savage: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 01 Dec 2004 10:53:38 -0800 To: Tim Bunce <Tim.Bunce@pobox.com>
At 10:39 AM 12/1/2004, you wrote:
>On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote:
> > On Wed, 1 Dec 2004 09:46:24 +0000, Tim Bunce <tim.bunce@pobox.com> 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.
Hi,
In our case we have several databases in a replication line using mysql. In
some cases we might want to connect to a server other than the first in
line, but most often we connect to the first in line/master. I also wanted
to make sure that if the script happened to be running on the master local
host that it would not connect using the host name and end up using TCP on
localhost.
Does that make any sense? I am not sure now that I think about it why I
could not just store the DSN for everything, but only separate out the
hostname. But then that is all I am doing anyway.
+-------------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+---------------+------+-----+---------+-------+
| dbname | varchar(40) | | PRI | | |
| dborder | tinyint(2) | YES | | NULL | |
| ip | varchar(15) | | MUL | 0 | |
| servername | varchar(100) | | PRI | | |
| username | varchar(20) | | | | |
| password | varchar(20) | | | | |
| raise_error | enum('1','0') | | | 1 | |
| autocommit | enum('1','0') | | | 1 | |
+-------------+---------------+------+-----+---------+-------+
I don't use the IP right now, but record it anyway. The server name is
important because I use the localhost name to match up with that, and if it
matches then don't add in the hostname to the connect string.
I just looked at DBIx::DBH and I have to say I don't get it. Why is that
any easier than the default?
I thought at first this thread was talking about managing connections..
Thanks,
Eric
>Tim.
- Next message: Ron Savage: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- Previous message: Tim Bunce: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- In reply to: Tim Bunce: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- Next in thread: Ron Savage: "Re: DBIx::DBH - Perl extension for simplifying database connections"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
