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:
- 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.
- 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.
- 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.
- 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