I received from suggestions via email on how to improve my module DBIx::Connect. In case you are not familiar DBIx::Connect, it is a module designed to store and retrieve information about how to connect to databases via DBI, optionally connecting to them as well.

It will work with any of the common DBI wrappers. In addition to reading configuration info from a file DBIx::Connect will overwrite/add file configuration supplied on the command-line via Getopt::Long-style arguments, DBIx::Connect is AppConfig-based... of course one wonders how viable this tech stack will be if TheDamian's Getopt::Declarative supercedes Getopt::Long in popularity, which is what often seems to happen with con-ware.

Anyway, I recently received a request for some more functionality, but I wanted to proceed democratically, meaning, what gets added is not based on what I think is right or what he thinks is right, but what most of us think is right. Now, this is not quite the Quaker quorum, but it is better than assuming a dictatorial stance on the issue. So here are the suggestions for improvement. Tell me what you think about these and also tell me what you think is lacking that wasn't mentioned:

  1. Right now DBIx::Connect requires a DBIX_CONN environmental variable to define where the config file is. Martin think it might be a good idea to make having this variable optional and instead be able to specify the config file via the command-line and/or default it to a certain file in the User's home directory.
  2. This is just for completeness, but both me and Martin have settled on AppConfig as the basis for file configuration. I had a bit of an itch to use XML::Simple since it is bundled with ActiveState and since people out-of-the-know tend to think you know what you are doing when you can mention a word like "XML" in conjunction with your product. But then we would lose all the power of AppConfig and it's clean integration with Getopt::Long. Not to mention I would probably have to write an XML validator to make sure the files were right.
  3. Allow for the DSN to be specified on the command-line since this is all that DBI needs in some cases. I am not in favor of this. I would much rather take the time to put the DSN info in a file than to do it via the commandline. Part of this is for accountability reasons. The other part is that DBIx::Connect is for Software Engineering not for off-the-cuff scripting.
  4. Patch test.pl so that it uses the now-standard dbi:ExampleP driver. This would be OK, but this must be a 5.8.0 thing and many people are still on 5.6.1. Heck, if you are doing Interwoven TeamSite Perl on this day 12/25/2002, then you are stuck with 5.005_03, I kid thee not.

So, please critique these suggestions and also throw in any others you might have. Over and out, merry christmas.

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: Critique of DBIx::Connect Requested
by Aristotle (Chancellor) on Dec 26, 2002 at 18:28 UTC
    The other part is that DBIx::Connect is for Software Engineering not for off-the-cuff scripting.
    Not to comment on the other assertions as I have no database experience, I don't like the implications of this sentence. It seems to go against the grain of Perl's spirit (you know, "simple things [...]"). I don't think it is any help in accountability as you can just make a file in /tmp and rm it immediately after launching the script, but that's a subjective issue.
    Patch test.pl so that it uses the now-standard dbi:ExampleP driver. This would be OK, but this must be a 5.8.0 thing and many people are still on 5.6.1.
    IMHO it is unwise at this point to target 5.8. On the other hand, the suggestion as such is a thoroughly good one; I'd consider patching test.pl such that it checks for the Perl version and proceeds accordingly.

    Makeshifts last the longest.