Once upon a time, at my very first job out of college. I had to write a database-oriented Perl script. I ran my script in a dev environment and then handed it over to a sysadmin who then altered the connect string at the top of the program to run it in his production environment.

Much later (about 2-3 years or so), I thought there should have been some better way to do this... to move the variation in program behavior out of code and into configuration.

I had been submitting patches to the author of DBIx::Password so that his module would work with packages such as Alzabo and DBIx::AnyDBD which have a special way of connecting to DBI databases, but he kept rejecting them, on the grounds that his module was designed to keep connection information private and there should be no way of seeing the connection information in cleartext.

So, I created DBIx::Connect, which is based on AppConfig. I am very happy with this module. belg4mit thought it would be a great way to catalog database connections for EZDBI but Dominus insisted that EZDBI would have no external dependencies. I have a co-developer but we have not done much to the module after our initial collaboration, after all, how much variability is there in connecting to databases?

Recently, on the #perlhelp IRC channel I learned of a neat module called autobox, and of course had to check out what other modules such a first-class programmer had made. His Xelig provides clean-cut MVC with calling conventions along the lines of HTML::Seamstress and PeTaL. But most relevant to this post is his XML::Object::DBI which provides DBI connection handles, but also a rather neat way of cataloging SQL, reminiscent of Class::Phrasebook::SQL and also retrieving the SQL without the prepare-execute-fetch ritual.

So anyway, click away to your heart's content... and let me know how you feel database connections should be cataloged... oh! I almost forgot probably the most widely used one: Ima::DBI, which is part of the ever-popular Class::DBI framework. I am working on something similar for DBIx::Recordset via the "living try-as-you-read" documentation in DBIx::Recordset::Playground which is based on DBSchema::Sample.

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality.

Replies are listed 'Best First'.
Re: DBI database connection support and more
by perrin (Chancellor) on Sep 18, 2003 at 19:58 UTC
    I looked at Xelig a few months ago, and frankly this guy comes off as arrogant and rude. The POD for that module contains the following:

    AVOID

    XSLT, Template::Toolkit, Mason, HTML::Template, PHP, JSP, ASP, PageKit, EmbPerl, ePerl, ZPT, TAL &c.

    That's pretty obnoxious, especially considering that the documentation for Xelig is almost non-existent and the module is sorely lacking in features compared to some of those other systems. It's especially odd since Xelig seems closer to TAL than to XMLC, which is referred to as the inspiration for this. And what's with calling the template processing method MVC? As far as I can see from the docs, there's nothing there but the V part.

    XMLC always sounded like a bad idea to me because it adds an extra compile step every time you change any of the HTML templates and because it only supports explicit manipulation through a DOM tree (at least that was the story last time I looked). Xelig appears much more similar to Petal, but I would recommend Petal over Xelig since it has documentation, a mailing list, and an active base of users.

    This guy may have a lot to offer to the Perl community, but a little more humility would go a long way here.

[reply]

      Too true. autobox looks rather neat, but it provoked a big flamewar on p5p. By itself, that's hardly unique, but the same author also wrote Util, which I'd point to as an example of a poorly thought-out module.

[reply]
        That flamewar provided me with stitches in my sides for weeks. I still go look up this response by Chip Salzenberg when I need to laugh at something.

        It was *brilliant*

        -- am
[reply]
Re: DBI database connection support and more
by adrianh (Chancellor) on Sep 18, 2003 at 21:39 UTC
    and let me know how you feel database connections should be cataloged

    I don't think that there is "a" way. Depends on your application. Treating the DBI specific configuration information separately from the rest of your applications configuration options seems counterproductive to me

    I usually put DBI info wherever the rest of the applications configuration information lives. A YAML file has been a recent popular choice.

    Using the environment variables DBI_DSN, DBI_USER and DBI_PASS can be another useful way of passing the info in - and has the advantage of being built into DBI.

[reply]
      Using the environment variables DBI_DSN, DBI_USER and DBI_PASS can be another useful way of passing the info in - and has the advantage of being built into DBI.
      Yeah it certainly depends on the situation... I live in a garden of databases here... Sybase, MySQL and SQL2000... also , we have several databases on each of these whose logical information is the same (name, id, address ,email, etc...) but whose concrete field name varies. So I need to warehouse connections and table field names.

      YAML was attractive to me but I would rather just pure Perl as I know the syntax and have had the parser flat out break without good error reporting on some .yml trial files of mine.

      Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality.

[reply]
        Did you file bugs for those YAML defects? I'd like to see those files.
[reply]
Re: DBI database connection support and more
by bradb (Sexton) on Sep 19, 2003 at 21:02 UTC
    The easiest way I've found is to use an environment variable to name the application-specific configuration file.

    So, for our credit card payment processing system, the config file lives in an environment variable called MERCHANT_CONFIG_FILE, which might then contain: 

    [Database]
username = bradb
password = god
hostname = foo
database = bar

    [download]
    Then parse it with something like Config::IniFiles and you're good to go. Of course, this can be applied to more than just database connections.
[reply]
[d/l]
      I find that this technique works well with a system for which you have multiple deployments, because it keeps hardcoded information specific to the deployment out of CVS. (Of course it shouldn't be hard-coded in the first place but I digress).

      For a CGI system under Apache you can just use a SetEnv directive in your httpd.conf to set MERCHANT_CONFIG_FILE and you're set; unless your httpd.conf is in CVS of course. :)

[reply]
Re: DBI database connection support and more
by drfrog (Deacon) on Sep 20, 2003 at 18:44 UTC
    i use DBI str8 up all the time!

    i know it probably seems shameful, but i have yet to find anything that learning it would seriously help me out more than take up my time! Im like this in my programming, especially when there is a deadline!

    that said lately i have been looking at ways to do this, i mean you cant store dsn entries in a database if you dont know the database parameters now can you!?
    :)
    more often than not i store it in a simple file to require at start of program, iirc, someone at my old work had a 'DBI::DSN' type module which basically allowed the config stuff to be store in a file
[reply]

Back to Meditations