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

Mike Pomraning 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 mailing list