Ooopps - can we get the DBI mailing lists to reply to the list instead of the sender by default?
On Fri, Mar 14, 2008 at 10:34 AM, Jonathan Leffler < [EMAIL PROTECTED]> wrote: > > On Fri, Mar 14, 2008 at 9:19 AM, Dean Arnold <[EMAIL PROTECTED]> > wrote: > > > Jonathan Leffler wrote: > > > On Fri, Mar 14, 2008 at 5:53 AM, <[EMAIL PROTECTED]> wrote: > > > > > >> I have been playing about with scrollable result sets (Cursors) > > >> in Oracle/OCI and have noticed that there has been some discussion > > about > > >> it before on the list > > >> > > >> You can find the discussion here > > >> > > >> > > http://perl.markmail.org/search/?q=list%3Aorg.perl.dbi-dev+fetch_scroll#query:list%3Aorg.perl.dbi-dev%20fetch_scroll+page:1+mid:xqwmgau3zesiyo7n+state:results > > >> > > >> and here > > >> > > >> > > http://perl.markmail.org/search/?q=from%3A%22Tim+Bunce%22+scroll+cursor#query:from%3A%22Tim%20Bunce%22%20scroll%20cursor+page:1+mid:t3xvtu3rcqarszsx+state:results > > >> > > >> Reading through these I see that basically each Database has its own > > >> flavour or scrollable results set from a select i.e. > > >> > > >> Informix Scrollable and updateable > > >> MySQL semi Scrollable > > >> Oracle Scrollable and read only > > >> SQLServer Scrollable and read only > > >> Scrollable and updateable > > >> > > >> So my proposal is to stub in > > >> > > >> fetch_scroll > > >> > > >> in DBI > > >> > > >> and let the DBD drivers write their own implementation > > >> > > >> This would be the same as "bind_param_inout_array" which is stubbed > > in but > > >> not implemented in DBI > > >> > > >> The proposed sub would be like this > > >> > > >> bind_param_inout_array => { U =>[1,2,'[, \%attr]'] } > > >> > > >> so there will be an attribute param to pass in any commands/setting > > that > > >> are needed for the fetch. > > >> > > >> The advantage of this is we get something that would be customized > > for > > >> each DBD implementation of course the disadvantage is we do not have > > a > > >> pure Perl implementation of his functionality. > > >> > > >> Any thoughts,comments or even insults;) are welcome > > >> > > > > > > Sounds good to me. Will there be a standard set of 'scroll actions'? > > > > > > [...] > > > > > > Or do we need a more general hash to pass values in? > > > > In DBI's spirit of ODBC/SQL CLI conformance, presumably the > > attributes should be > > > > SQL_FETCH_NEXT > > SQL_FETCH_PRIOR > > SQL_FETCH_FIRST > > SQL_FETCH_LAST > > SQL_FETCH_ABSOLUTE > > SQL_FETCH_RELATIVE > > SQL_FETCH_BOOKMARK > > > > with values as defined somewhere in ODBC's header files. > > > > Those names and values are fine with me as long as DBI provides them to > (a) Perl-based DBI users and (b) to DBD driver writers. That is, DBI needs > to provide the names in some way, maybe like it does with sql_types (use DBI > qw(:sql_types); IIRC). > > And we need to define the basic (read common) attributes for the hash. I > think that means > > fetch_orient > fetch_offset > > if the OCI names are semi-standard. I'm happy to be flexible about the > names. This is crucial if anyone is to have half a chance of writing > driver-neutral code in Perl using DBI. > > We also need a defined mechanism to find out if the driver support scroll > cursors. There are ODBC attributes to describe things up the wazoo - which > one is relevant so that drivers with scroll support can ensure the user gets > the correct answer. > > > > > Gruesome details of ODBC's SQLFetchScroll are here: > > > > http://msdn2.microsoft.com/en-us/library/ms714682(VS.85).aspx<http://msdn2.microsoft.com/en-us/library/ms714682%28VS.85%29.aspx> > > > > Does this page explain how cursor bookmarks are set? (Yes, I'm being > lazy.) > > I'm not trying to be obstructive (however much I'm succeeding) -- I very > much want DBI to support scroll cursors. However, it has to be usable > support, and common support, and I think this much is necessary. > > > -- > Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h> > Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org > "Blessed are we who can laugh at ourselves, for we shall never cease to be > amused." > -- Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
