Re: [Ruby-DBI-devel] When to call finish?

[Michael N. <uu...@rz...>]

Paul DuBois wrote:
> When you generate a statement handle for processing a statement,
> is it intended that you invoke finish only when the statement
> returns a result set, or also for statements such as INSERT, DELETE,
> etc.

This, of course, depends on the database. However, better call finish. 

> That is, which is these is better:
> 
> sth = dbh.prepare("INSERT ....")
> sth.execute
> sth.finish

This is even more secure:
 
  dbh.prepare("INSERT ....") do |sth|
    sth.execute
  end

> or:
> 
> 
> sth = dbh.prepare("INSERT ....")
> sth.execute
> # (no finish call here)

If you do this 100 times or less in a loop, you'll probably run out
of cursors (Oracle-DB).

Ruby's GC will reclaim memory and free the statments, but creating cursors
is faster than the GC can interact.

> Also, in the Perl DBI, use of finish is discouraged if you fetch
> all the rows of the result set, because it gets invoked for you and
> is redundant.  It's used when you don't fetch everything and need
> to tell DBI explicitly to cancel.  From my reading of the Ruby DBI
> docs, I don't get quite this sense about finish.  Is it deprecated
> after a complete-fetch loop in the same way as for Perl?

This might get you into problems and is perhaps not the best programming style,
as you have to know the internals of DBI to understand what's going on.
And who knows, this might change in the future!

If you want to fetch all rows, use the select_all methods (with or without 
iterator). Otherwise better call finish, even if it gets called implicitly 
by the DBI (there's no real performance hit in doing so, it's just another "if" stmt).

The best is, you use the block-forms of the methods whenever possible, as they
call finish or cancel when required for you.  


Regards,

  Michael