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 :)
> 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.
How about you outline in rough pseudo-code what you're thinking of
and we'll help point you in the right direction?
> 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 :)
> 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.
>>>>
>>>
>>>
>>
>>
