Re: [regrep-query] Iteration Support for Queries v0.2

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Hi Len,

My half baked thoughts on supporting true cursors would require adding support for
transactions (a planned work item that did not make the cut for V3). Clients would
have the ability to begin a transaction and then do iterative queries. The queries
will see a constant result set during the transaction. The client would then commit
the transaction. Alternatively the transaction would timeout after some policy
specific interval. While the transaction is ongoing, others will be able to modify
the result set. However, the iterative query client will see a constant result set
(copy or original) throughout the transaction.

The above model is quite doable, but requires more thought and thus deferred for
now to cut scope. We have too many things on our plate and precious little time and
resources.

--
Regards,
Farrukh


Len Gallagher wrote:

> At 04:36 PM 7/26/2002 -0400, Farrukh Najmi wrote:
> > > Issue #2: Should the specification require that the Query be submitted
> > > separately from the iterations? This is logically cleaner, but doesn't
> > > really avoid the ambiguities unless additional requirements are placed on
> > > the Registry to implement transactional semantics or to hold large
> > > "complete" result sets for indefinite time. The SQL notion of Declare
> > > Cursor and Fetch from Cursor use this approach and have additional
> > > INSENSITIVE and SCROLL options on DECLARE CURSOR that a client can use to
> > > tell the database server whether certain ambiguities must be avoided during
> > > subsequent Fetches. ODBC and JDBC also use this approach with a clear
> > > separation between the Query, its result set (or sets), and cursor
> > operations.
> >
> >I do not follow the above issue. Does it get impacted given the resolution I
> >proposed for Issue #1?
> >If nt please clarify.
>
> The only issue is whether one should have two separate facilities, as you
> suggest in your comments, or one facility that can be extended in an upward
> compatible manner to handle cursor extensions. I see pros and cons for each.
>
> -- Len
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>