in reply to Re: No Fear: decoupling your application from the database
in thread No Fear: decoupling your application from the database

Thanks for the input. The problem I have with &DBI::fetchrow_hashref is the same problem we have with "SELECT * FROM that". Essentially, what we're doing is trying to fetch both the data and the metadata. For a robust application, we should fetch the data based upon our foreknowledge of the metadata. For instance, consider the following:

while (my $data = $sth->fetchrow_hashref) { my $total = $data->{subtotal} * $tax_rate; # do stuff }

Now imagine that the above code generates the following warning:

Use of uninitialized value in multiplication (*) at foo.pl line 30.

We have no way of knowing, from that error message, whether or not the problem is an undefined value in the hash or a non-existent hash key (assuming that we know the $tax_rate has been defined). Problems like this are more prevalent when we're essentially fetching two types of data. Also, many argue that we shouldn't be doing direct data access like that. If we were to retrieve the data through a clean API rather than by reaching directly into the hash, we can tweak the internals to ensure that we're returning expected data and handling errors gracefully.

In glancing at SPOPS, I can see that it looks very interesting and has some features I've wanted in Class::DBI. I'll dig into it more. Given my lack of time, I'll probably maintain my focus on Class::DBI, but include SPOPS and perhaps update my presentation in the future. Also, quite frequently at our Perl Mongers meetings, people start asking gnarly questions about how a particular technology works. I suspect that I can answer that much better about Class::DBI than SPOPS :)

Also, I completely agree that Class::DBI is not necessary for an abstraction. I'll present other models including a hand-rolled PersistentObject module that I wrote prior to discovering POOP. I've also dug up an example of this in Python that is perfect as an example of how not to do this. It's not that it's written in Python, but that it's intrisically tied to the column names in the database.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Replies are listed 'Best First'.
Re: Re: Re: No Fear: decoupling your application from the database
by perrin (Chancellor) on Mar 26, 2003 at 21:03 UTC
    Hmmm. I'd say fetchrow_hashref is not as bad as "select *" in most cases, since when you use "select *" you could end up getting a whole bunch of extra rows you don't want, or get the columns in a different order. Using the name of a column in fetchrow_hashref is essentially the same as using the name of the column in a SQL statement. (Of course I don't use it because of the performance hit...)