Tim Bunce wrote:
On Wed, Mar 19, 2008 at 07:15:07AM -0400, John Scoles wrote:
Well after playing with some of the code in DBI and running into a few
problems I was not able to easily get over I will have to hold up on my
idea of a DBI version for now.
You know, you could always ask for help :)
Main reason is why I suspended work on it is I need to get out release
1.21 out before the end of the month as I will be able to spend near 0 time
on it for most April. As well some clients of Pythian are interested in
using it.
Mostly I was not able to figure out an easy way of where and how am I going
to store/cache the 'record set' data, I did try to use DBI::Gofer for this
but still need some more time to get it right for all cases.
Sounds like you'd gone off in a wrong direction. I can't see any need
for gofer to be involved.
Yep sure did on that one but at least I know more on gofer now.
How about you outline in rough pseudo-code what you're thinking of
and we'll help point you in the right direction?
Ok I will do that with some of the old code that I found on the list
So I will for now just implement 'Scrollable Cursors' as a private function
in DBD:Oracle. That way I can get the functionality out there so others
can see how it works.
With docs, I trust :)
Plenty and lots of code comments as well.
Cheers
John Scoles
Expect to see the first RC of 1.21 in the next day or two.
Great. Thanks John.
Tim.
Cheers
John Scoles
[EMAIL PROTECTED] wrote:
Opps my night for boo-boos
Anyway here is my whole message
Ok one bigger patch to DBI comming up
I guess I can use the following for
SQL_FETCH_NEXT
SQL_FETCH_PRIOR
SQL_FETCH_FIRST
SQL_FETCH_LAST
SQL_FETCH_ABSOLUTE
SQL_FETCH_RELATIVE
which are generic enough for almost every Database
Again like my first proposal we could have these entered in as attribs or
we could have a simple two param sub like this
fetch_scroll($oreinetation,$offset);
or a three one like this
fetch_scroll($oreinetation,$offset,{attribs});
I will work both out and get back to the list one it the only proble I see
is knowning were one is in the cusor
cheers
On Fri, Mar 14, 2008 at 08:53:04AM -0400, John Scoles wrote:
So my proposal is to stub in
fetch_scroll
in DBI
and let the DBD drivers write their own implementation
I'd _much_ rather one or driver implemented the functionality as
driver-private methods before we try to define the DBI by guesswork.
I'd also _much_ rather fetch_scroll() wasn't added until a fallback
implementation existed for it in the DBI. In the same way that
execute_array() and related methods weren't added until there was a
fallback implementation in the DBI.
It can't be that hard to add read-only cursor support.
The guts of it would be something like...
- A $sth->{FetchedRows} attribute containing an array ref
- dbih_get_fbav() would see that attribute and instead of
reusing the same row buffer would allocate a new one and push it
on the end of the $sth->{FetchedRows} array.
- fetch_scroll() then just needs to have a concept of 'current row'
and can use $sth->{Active} to tell if there may be more to fetch.
This would be the same as "bind_param_inout_array" which is stubbed in
but
not implemented in DBI
That's an (unfortunate) exception to the rule :)
Tim.
