[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