Re: DBI and finish (risk of calling finish twice)

Now, I get how it's not needed, but the warnings in this documentation appear a bit hyperbolic. Are these warnings exaggerated?

Nope, sounds rather tame :)

Or is legacy code that still includes finish calls as an idiomatic way to communicate intent actually a “mistake” instead of merely wasted effort?

Its both :) its also neither :)

Its definitely not "idiomatic way" since the DBI docs tell you don't; Its part of the public API, the drivers have to implement it, but there isn't a single usage shown in the examples in DBI.pm, and you don't need or want it 99/100, so anytime it shows up its 99/100 a mistake , typically cargo-cult-ed

Also, documenting intent, what intent? That you're finished with the statement handle? I think undef $sth; documents that more clearly and universally :)!

However, I would like to understand the actual risk of needlessly calling finish, or if this is just an effort to get people to streamline their code?

The risk is an error message gets lost (esp if you're not using RaiseError); Calling finish modifies $sth attributes ... https://metacpan.org/source/TIMB/DBI-1.631/DBI.xs, https://metacpan.org/source/TIMB/DBI-1.631/Driver.xst, https://metacpan.org/source/ISHIGAKI/DBD-SQLite-1.42/dbdimp.c

I don't think its an effort to get people to streamline their code :) Because

Its kind of like calling close $fh; except that it isn't

Its more kind of like calling close $fh; close $fh; ... the $! gets obliterated

Its not unlike calling $foo->DESTROY when undef $foo; will do that

Its like using opendir/readdir/closedir ... its lower level interface you don't need most of the time

Possible use case for finish, is user clicks cancel button in a gui, there are still many results left, so program calls finish ... but in reality 99/100 you'd simply destroy undef $sth ... and you'd be handling errors with RaiseError... not manually checking

Yes, I've frequently ~~written~~ copy/pasted $sth->finish even when all I really wanted was $sth->commit; and undef $sth; would have (probably) accomplished both (:IIRC...:); I'm not afraid to cargo-cult :)

Comment on Re: DBI and finish (risk of calling finish twice) Select or Download Code

Replies are listed 'Best First'.
Re^2: DBI and finish (risk of calling finish twice) by andal (Hermit) on Jun 26, 2014 at 09:59 UTC
Actually, calling $sth->finish becomes important only on the cached handles when not all of the data was fetched. Otherwise, next "execute" on that handle may result in error. Though it all depends on the actual driver. Many (or is it all now?) drivers automatically do "finish" for the handles that are "executed" again. So, if one works with such driver, then one does not need "finish" at all. BTW, the above behavior of the drivers potentially masks errors of simultaneous use of the same handle :) YMMV. As to "dangers" of using "finish", this might be exaggerated. After all, one should check for errors right after the call to "fetch", if this is not done, then clearing that error state later by "finish" does not play any role. Mostly, these "finish" calls are just useless. IMHO. BTW. Doing "undef $sth" on statement with active transactions results in ROLLBACK, not COMMIT. At least this is what I was getting with SQLite :)	[reply]
Re^3: DBI and finish (risk of calling finish twice) by Anonymous Monk on Jun 26, 2014 at 10:14 UTC
... cached ... Though it all depends on the actual driver ... I doubt that :) See inside DBI.pm look for "sub prepare_cached"	[reply]
Re^4: DBI and finish (risk of calling finish twice) by andal (Hermit) on Jun 27, 2014 at 06:22 UTC
Well, "cached" does not mean only "prepare_cached" :) Whichever caching mechanism is used, prepared statement with unfinished fetch may introduce problems. I guess you've seen the description of $if_active flag for DBI::prepare_cached :) That is why, calling finish in this case might be important.	[reply]


The stupid question is the question not asked
	PerlMonks