Rob Kinyon <[EMAIL PROTECTED]> writes:
> I have a philosophical issue with SQL Phrasebooks in general. This may
> have to do with the types of applications I tend to write, so please
> take me with a grain of salt.
>
> My applications tend to have a DBI wrapper that provides two pieces of
> functionality:
0) Cataloging your database connection information,
e.g. DBIx::Connect, Config::DBI, DBIx::DBH, DBIx::Password
> > 1) Business-level functions for accessing datastores (databases and other
> > stuff)
that sounds like DBIx::AnyDBD to me:
use DBIx::AnyDBD;
my $db = DBIx::AnyDBD->connect("dbi:Oracle:sid1",
"user", "pass", {}, "MyClass");
my $foo = $db->sales_to_date('2005-03');
my $blee = $db->month_to_date(2004-12');
> > 2) Functionality for generating SQL on the fly, using somewhat complex
> graph theory
I remember Ovid mentioning he did a similar thing at his previous
company. I don't believe either of you have released these powerful
modules to CPAN.
> >
> The first is for things like "Given this username and password, can
> the person log in?". The second is for reports. My reports aren't your
> grandma's reports - you have a list of options to choose from and the
> app figures out what SQL to run from there, including all the table
> joins.
any code samples to look at?
> >
> So, what need do I have for a phrasebook? I can understand, to some
> degree, putting the statements from the first grouping into a
> phrasebook, but they're already behind a layer of abstraction and in
> one place. So, doesn't that mean I've satisfied the benefits of a
> phrasebook?
yes, I see your point. You custom-generate SQL
dyanmically. SQL::Phrasebooks are for storing static SQL. They are
completely inappropriate for dynamic SQL.
--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
_______________________________________________
sw-design mailing list
[email protected]
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
