[Ruby-dbi-devel-new] BaseStatement#cancel default implementation
mjp at pilcrow.madison.wi.us
Thu Mar 20 20:58:23 EDT 2008
On Thu, Mar 20, 2008 at 8:58 AM, Erik Hollensbe <erik at hollensbe.org> wrote:
> > # class StatementHandle
> > def execute(*args)
> > cancel if fetchable? # <--- fetchability check is new
> > ...
> I'm honestly not sure how to parse this. We especially don't want to
> cancel the statement if it's fetchable, did you mean to use 'unless'
> instead of 'if'?
Nope -- we always want to dismiss any queued results from a previous
query. As it happens, this is the current (and desirable) behavior
and the above was unnecessary: execute() summarily calls cancel()
before doing anything, and cancel() itself checks for fetchable?ness.
> > 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.
> I don't want to distract you from improving DBI at all, but I have no
> intention of adding features like this in this release. Right now my
Do you mean features like externally visible API convenience
extensions (e.g., "prepare_cached"), or features like internal driver
improvements which offer what some would argue is the minimum
functionality required for a useful, safe and correct DB abstraction
(e.g., DBD::Pg::please_please_use_native_prepared_statements)? As you
might guess, I've an opinion about the relative importance of the two.
> > 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
> Instead of just giving them four options, why not give them a series
> of state reporting methods (e.g., cancelled? which would report if if
> the statement was cancelled prior to a new execution) and let them
> work with it themselves, and allow the option of being able to finish
> cached statements after retrieving them.
Ack. fetchable? already provides a suitable check (though active?
would be a clearer synonym, IMHO). The same check, FWIW, could be
used for someone concerned about re-execute()ing an active sth.
More information about the Ruby-dbi-devel-new