dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

Given a $dbh, how would I go about getting the following information: Assume I'm using the latest DBI and, if needed, I'm using DBD::mysql, but I'd like a DB-agnostic solution, if possible.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re: Querying a $dbh
by Fletch (Bishop) on May 01, 2008 at 19:14 UTC

    Waaaaaaay down at the end of the DBI perldoc it has a section "Database Handle Attributes" that shows the "published" attributes that are available for pulling out of the $dbh hashref. The first two items in your list are obtainable through the Name and Username keys (and there's a Driver that you can use to retrieve the database driver name the handle is using).

    Update: Just to clarify I mean "published" in the sense of "it's explicitly documenting that the hashref for the handle will have those keys and it's implicitly OKing breaking encapsulation to retrieve them".

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      DBI handles are actually refs to tied hashes, so using the documented hash elements isn't breaking encapsulation in any sense; anything you do to the hashref is very much a part of the API.
Re: Querying a $dbh
by apl (Monsignor) on May 01, 2008 at 19:14 UTC
    DBI has environment variables for database, user and password (DBI_DSN, DBI_USER and DBI_PASS respectively), but they aren't based on dbh.

    Would it be possible to define an Array of Hashes that associated these three values with the DB handle as the connects were done?

Re: Querying a $dbh
by doom (Deacon) on May 02, 2008 at 03:44 UTC
    Can I ask what you're trying to do? This sounds like a vaguely familiar problem, I'm trying to remember when I've seen it before. I think I was trying to write a set of routines that would have a $dbh passed in as an argument, but then I realized that the routines needed to know the connection parameters also (probably so they could reconnect if the connection was dropped, or something like that). It seemed neater to me to be able to just pass one piece of information rather than three or four, but that boxed me in later -- I think I resolved the problem by creating yet-another-class to handle making database connections, and so I had a new object that was less cagey about protecting the connection info.