It sucks being in the latest timezone in North America; it makes it that much
more difficult to catch up on all the mailing list traffic.
Anyway, thanks for all the valuable feedback. I like the DBIx::Export2Hash
name, mainly because there's less ::'s in there.
Regarding the configuration parameters, I'm not sure if I want to make the
configuration file a part of the module itself. An EXE_FILES entry is
defined in the Makefile.PL for the sample script that'll be distributed with
the package (which is the script I'm using here at work) and I feel that this
script should use Config::General. Instead, one could simply say:
$config = { ...magic goes here... };
DBIx::Export2Hash->export($config);
## or ##
DBIx::Export2Hash->export(sql => $sql, index => [EMAIL PROTECTED], hash => \%myHash);
My main goal is to make the module itself as simple as possible; besides, if
it is harder to use than, say, a DBI call with hard-coded indexing rules,
then whats the point of the module? The configuration file stuff will simply
be a wrapper around this module, so I can take my hackish bits out and
support a more modular framework.
A subclass of this will probably be something like
DBIx::Export2Hash::BerkeleyDB, which handles the tie'ing of a DB file.
One last comment. Since it really takes SQL statements and outputs the result
to a hash (the "export" part being an implied aspect of invoking an SQL
query) would it not make more sense to call it DBIx::SQL2Hash?
--
/* Michael A. Nachbaur <[EMAIL PROTECTED]>
* http://nachbaur.com/pgpkey.asc
*/
"Ford," he said, "how many escape capsules are there?"
"None," said Ford.
Zaphod gibbered.
"Did you count them?" he yelled.
"Twice," said Ford
