[Ruby-dbi-devel-new] BaseStatement#cancel default implementation

Mike Pomraning mjp at pilcrow.madison.wi.us
Thu Mar 20 00:41:25 EDT 2008


Proposal:  DBI::BaseStatement#cancel should simply read and discard
any remaining rows, something like:

    # class BaseStatement
    # Discard all pending rows, if any, making the statement ready for
re-execution.
    # Subclasses are free to offer more efficient implementations, of course,
    def cancel
       row = "not nil"
       until row.nil?
         row = fetch
       end
       nil
    end

    ...
    # class StatementHandle
    def execute(*args)
       cancel if fetchable?  # <--- fetchability check is new
       ...

Having taken a crack at true (server-side) prepared statements in the
Pg driver (Tracker "Patches" #18925), I started toying with a
DatabaseHandle#prepare_cached(), ala "prepare_cached" from perl's
DBI.pm.

Now, DBI.pm raises the question of what to do when a #fetchable? sth
(DBI.pm analog: $sth->{Active}) is pulled from the cache.  DBI.pm by
default complains about this situation, but resets the sth with
$sth->finish, and moves on.  We can't simply imitate that behavior,
since our #finish is more like the DBI.pm's $sth->DESTROY.  Our
#cancel comes closest, however, to a bona fide prepared statement
reset.

Reactions?  There's still the separate question of what
safety-checking #prepare_cached might look like, e.g.:

   dbh.prepare_cached(sql, :if_active => ACTIVE_HANDLE_WARN) #
default, complain but cancel() the cached sth
   # ACTIVE_HANDLE_CANCEL ... silently cancel() the cached sth
   # ACTIVE_HANDLE_IGNORE ... don't bother checking cached sth for
fetchable?ness
   # ACTIVE_HANDLE_REPLACE ... cache a newly prepared sth instead,
without mutating the old one in any way

-Mike


More information about the Ruby-dbi-devel-new mailing list