[I've no time to study this in depth so it's just a quick skim
without looking at the code, sorry. I've been ignoring dbi-dev for
a while due to pressures of work etc, I hope that'll improve soon.]
On Fri, Jan 10, 2003 at 11:58:11AM -0800, Jonathan Leffler wrote:
> Dear Tim,
>
> Here is a working proof of concept for scroll cursors in pure Perl.
Thanks.
[I should explain to the others on the list that Jonathan said he
wanted to add scroll cursor support to DBD::Informix and wanted the
DBI API to be extended to cover it. I said I wanted the service to be
available to all drivers and so the best way forward was to implement the
default DBI behaviour and API first, then drivers can add their own
overriding functionality. This is exactly the development model that
worked well for execute_array() etc with Dean Arnold.]
> Issues:
> * How should the user tell prepare/execute that this will be used as a
> scroll cursor?
New method call, possibly:
$sth->set_attr(SQL_ATTR_CURSOR_TYPE, SQL_CURSOR_STATIC);
If you detect an ODBC v3 flavor you'd be right.
> * I envisage (a variant on) the %ctl structure actually being an
> attribute of the $sth, so that instead of being passed explicitly to
> the fetchrow_scroll_arrayref method, it would arrive with the $sth.
Yes.
> * I need to track down how (whether) to modify the %ctl structure so
> it contains the array directly rather than a reference to the array.
> * I need to track down how (whether) to remove some other references
> in the test code.
> * We need to decide whether to use strings to determine the fetch
> operation. They're simple, but...
Using
use DBI qw(:cursor); # or something like that
will import all the relevant SQL_* numeric constants including
SQL_FETCH_NEXT etc.
> * I assume we'd enforce rules that if a cursor is not started as a
> scroll cursor, you can't decide to use it as a scroll cursor after
> the (first) execute? Or is that after the prepare? I think it
> probably needs to be the execute that gets told about the
> scroll-ness since you would not know, in general, whether you have a
> fetchable statement until after the prepare has completed.
I'd say it's changable only until the first execute.
> * Are the implemented semantics of fetching before first and after
> last row correct?
It'll be whatever ODBC says it should be ;-)
> =head2 "Scroll cursors"
>
> $sth->execute_scroll([@vals]);
The plain execute method is fine. No need for a new one.
It'll be:
$sth = $dbh->prepare(...);
$sth->set_attr(SQL_ATTR_CURSOR_TYPE, SQL_CURSOR_STATIC);
$sth->execute(...);
... = $sth->fetchrow_scroll*
At a slight tangent, I'm also thinking of adding a bunch of
... = $sth->rowdata_arrayref;
... = $sth->rowdata_array;
... = $sth->rowdata_hashref;
which would return the data for the 'current row'.
Tim.
