Avoid $sth->finish
Kohackers -- I want to mention this because I've seen a lot of recent patches still using the old style of code calling $sth->finish() explicitly. I know a lot of the codebase still does this internally, but for Koha such usage is almost always wrong. If this were just my personal contention, I would couch this in terms of an RFC to deprecate the usage. But we don't get a choice here: DBI is telling us "don't do it". Please refer to the DBI perldoc<http://search.cpan.org/%7Etimb/DBI-1.608/DBI.pm#finish> : The finish method is rarely needed, and frequently overused, but can sometimes be helpful in a few very specific situations to allow the server to free up resources (such as sort buffers). When all the data has been fetched from a SELECT statement, the driver should automatically call finish for you. So you should *not* normally need to call it explicitly *except* when you know that you've not fetched all the data from a statement handle. The most common example is when you only want to fetch one row, but in that case the selectrow_* methods are usually better anyway. *Adding calls to finish after each fetch loop is a common mistake, don't do it, it can mask genuine problems like uncaught fetch errors.* That last sentence is the most concrete and important (hence my bolding). Moral of the story: don't do it. Or if you think you have to, at least comment why, like: $sth->finish(); # FIXME: leaving data unfetched, should rework query -- Joe Atzberger LibLime - Open Source Library Solutions
2009/6/4 Joe Atzberger <joe.atzberger@liblime.com>
Kohackers --
I want to mention this because I've seen a lot of recent patches still using the old style of code calling $sth->finish() explicitly. I know a lot of the codebase still does this internally, but for Koha such usage is almost always wrong.
If this were just my personal contention, I would couch this in terms of an RFC to deprecate the usage. But we don't get a choice here: DBI is telling us "don't do it".
Please refer to the DBI perldoc<http://search.cpan.org/%7Etimb/DBI-1.608/DBI.pm#finish> :
The finish method is rarely needed, and frequently overused, but can sometimes be helpful in a few very specific situations to allow the server to free up resources (such as sort buffers).
When all the data has been fetched from a SELECT statement, the driver should automatically call finish for you. So you should *not* normally need to call it explicitly *except* when you know that you've not fetched all the data from a statement handle. The most common example is when you only want to fetch one row, but in that case the selectrow_* methods are usually better anyway. *Adding calls to finish after each fetch loop is a common mistake, don't do it, it can mask genuine problems like uncaught fetch errors.* That last sentence is the most concrete and important (hence my bolding). Moral of the story: don't do it. Or if you think you have to, at least comment why, like: $sth->finish(); # FIXME: leaving data unfetched, should rework query
-- Joe Atzberger LibLime - Open Source Library Solutions
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
I've wondered about this myself, since Perl, being a dynamic language, should have some sort of destructor support. Thanks for looking into this, I'll try to avoid it in the future. -- Jesse Weaver
Jesse a écrit :
I've wondered about this myself, since Perl, being a dynamic language, should have some sort of destructor support.
Thanks for looking into this, I'll try to avoid it in the future. Hi Jesse,
how is your MUA configured ? (and what MUA do you use?) it's a "nighmare" to read your mails : * It does not remove the signature, so we get your answer after Joe sig+ mailing list signature * It does not quote what you're answering, so I don't see clearly what is your and what is your answered -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
2009/6/4 Joe Atzberger <joe.atzberger@liblime.com>
Kohackers --
I want to mention this because I've seen a lot of recent patches still using the old style of code calling $sth->finish() explicitly. I know a lot of the codebase still does this internally, but for Koha such usage is almost always wrong.
One way to avoid this problem is to not even create an $sth. For INSERT, UPDATE, and DELETE statements, I find that a * $dbh->do($statement)* is often sufficient. (The do() method can take bind variables, too.) For SELECT statements, I just use *$dbh->selectall_arrayref($statement, { Slice => {} }, @bind_variables)*. This will give me what I want in one shot without having to do the prepare/execute/fetchrow_hashref dance. AND there's no $sth for me to accidentally call finish() on, either. If you're pretty sure the result set isn't going to be huge, taking this approach will also save you from a lot of unnecessary typing. ---- A long time ago, I read an essay on Forth, and it had a quote that really stuck with me. It said that *the best way to solve a problem is to completely avoid it.* Structure the system such that the problem can't even exist. I really liked that. Buckminster Fuller <http://en.wikiquote.org/wiki/Buckminster_Fuller> (who was not a programmer (but who was a great man)) had a similar system design aesthetic. He was all about designing systems that made it impossible for certain problems to exist. To me, this is a profound and powerful problem-solving strategy, and this seemed like a good time to share it w/ the rest of you. :) --beppu
participants (4)
-
Jesse -
Joe Atzberger -
John Beppu -
paul POULAIN