Because DBI is a very popular module, my attempts to show what it is (a database interface) and what it is not (an abstract high-level tool for database use) raised some ire.
About a month later, chromatic authored a counter-article in which he attempts to show various means of using DBI with near equal expressiveness as the examples in my article.
Now, it is 2 months later, and I have had plenty of time for my ears to cease reddening at the sight of this article and a new recent thread has provided an excellent example to launch my counter-argument. It is a shame that perl.com doesn't have a forum like xml.com does, or we could discuss this so that all readers of the article could gain from the discussion. Anyway, section-by-section, I offer my comments on his article.
A recent article on Perl.com recommended that most Perl programs use the DBIx::Recordset module as the standard database interface. The examples cast an unfavorable light on DBI (which DBIx::Recordset uses internally).There was no attempt in my article to cast a negative light on DBI. The attempt was to cast a negative light on people inane enough to use a low-level database interface for high-level database tasks.
Various classes of programs will handle this differently. My preference is to die immediately, noisily alerting the maintainer. Other applications and problem domains might prefer to insert or to store potentially tainted data for cleansing later. It's even possible to store metadata as the first row of a table or to examine the table structure before inserting data.Every "handler" and metadata option you discuss above can be written in DBIx::Recordset by use of it's API, or by simply supplying the appropriate flag or coderef to it's pre-existing API functions. You might read the section on Record Filtering in its docs.
SQL statements are plain text, easily manipulated with Perl.This statement is my single biggest aggravation with your approach to database use from Perl. As you can see from this recent thread: Why use HTML instead of CGI? (codediscussion) it is much sounder to use functions and data structures which map to the structure of the target syntax than to do free-form text manipulation.
Unfortunately, you appear not to know that function calls and manifestly defined data structures lead to maintainable and understandble code and prefer to continue by saying:
It takes only a few lines of code and two clever idioms to produce a sane and generalized function to insert data into a table.But your generalized function call is nothing but the Recordset Insert() function. Do you want a proliferation of DBI extensions similar to what we have going on with CGI? 20-30 different modules, all with the same synopsis, same internal functionality, but different authors and potentially different calling convetions but all offering roughly the same functionality.
By showing this function your article is promoting un-needed diversity. I can just see all the DBI-users out there now, cutting and pasting that code into Corporate::DBI::Wrapper.pm when instead they could
perl -MCPAN -e shell shell> install DBIx::Recordset
Some coders may prefer a higher level of abstraction to hide tedious details for simple requirements. The drawbacks are lessened flexibility and slower access.It depends on what you mean by flexibility. If you mean flexibility in tweaking SQL queries you are right. If you mean flexibility to structure changes, either in the database back-end of UI front (CGI formdata, for instance), then this is not correct. As I showed in my paper, and as you managed not to address, one can commit front-end data to databases with Recordset in one-line regardless of changes in that input source in most case. As you can see from Programming the Perl DBI, the examples for committing CGI data to database are much longer. For database mutations, DBI and Recordset are comparable due to DBI's selectrow_hashref function.
In reply to Rebuttle to chromatics by princepawn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |