Woooie!?!
I didn't expect the firestorm this post would generate. From what I hear
people are either embedding SQL or writing their own utility module to
essentially do something along the line of:
$s->StartDBI ( DSN => 'somedsn_pointer') ;
eval {
$s->SelectSQL ( NAME => 'sql_select',
TABLE => 'sometable',
FIELDS => ['field1', 'field2', 'field3'],
WHERE => 'field1=?',
VALUES => $some_value_for_field1);
while ( my $return = $s->SQLGetArray( NAME => 'sql_select')) {
#do something $return - maybe complete a template object?
}
};
$s->EndDBI ( DSN => 'somedsn_pointer', QUERIES => 'sql_select', RESULTS =>
$@);
Where the different calls do the things hinted at in their name (i.e.
StartDBI opens the DSN and connects to the database in question, SelectSQL
would prepare the SQL select statement and execute it via DBI). This allows
the us to pass a native Perl structure which is reformatted to work with
DBI. We also get back scalars, arrays, or hashes that are easy to work with.
This is what we do here where I work. I still consider this embedded SQL
because a change to the table or even to the server could cause the program
to break in a lot of places. I think what I had in mind was some way to put
this type of processing into a layer where all the SQL related items are
essentially in a template file somewhere maybe a SQL::Template type thingy.
If this is something that people feel would be a worthwhile endeavor, let me
know and maybe when there's have a little free time in the Fall one could
write a CPAN module that has this functionality.
We had the conversation awhile back about adding redundant and unnecessary
crap to CPAN and I want to make sure something like this would be a good
thing or not.
Thanks,
--Joe Breeden
--------------------------
