[oslc-Reporting] OSLC Reporting - Paging

[Dave]

Thanks Tack. That is a great write-up of the issue.

I guess I've never considered implementation #1 because it's it's
difficult to implement and even if you do have an RDBMS/cursor holding
open a bunch of cursors does not seem very scalable. But, I can see
why you would want the query result to be a snapshot of the data at a
specific point in time.

Do we need to provide a way for services to declare which
implementation approach they use? (I hope not)

It might be useful to examine what other specifications say about this
issue, e.g. AtomPub for example.

- Dave


On Mon, Mar 22, 2010 at 3:50 PM, Tack Tong <tacktong at ca.ibm.com> wrote:
> Summarizing the Paging discussion in the Reporting WG call this morning. We
> haven't arrive any conclusion. Thus, encourage further discussion via email
> before next call.
>
> There are potentially two ways to implement Paging at service end.
>
> 1. Service does the query and caches complete resultset in memory/storage, then
> services one page at a time to the client. This approach would guarantee the
> validity of the resultset at time of query. However, the cache could
> potential expire before all pages are requested. Thus, need to specify how
> this exception situation should be handled. Also, there could be limitation
> on the server end on the size of the resultset it could handle due to
> resource limitation. (Note: Some Service may have a RDBMS underneath which
> would handle this via a DB cursor. I believe, from the end user perspective,
> this is similar to an application caching the resultset.)
>
> 2. Service does query for a page at a time (i.e. different queries for
> different pages) based on certain parameters. Note: It does not necessarily
> have to be based on record offset, though this could be one of the approach.
> Since records could potentially be changed in-between pages, there could be
> cases that the complete resultset aggregated from the pages could have
> duplicated, or missing, or changed records. This approach obviously would
> help the server side resource limitation. However, the client side would
> have to deal with duplicated, missing, and changed records.
>
> >From the Reporting client's perspective,
> 1. In the use case of ETL, duplicates and changed records could potentially
> be handled in ETL logic in pre-processing phase of data cleansing. Missing
> records could be a challenge.
> 2. In the use case of live reporting and document generation, duplicated,
> missing, or changed records would produce misleading reports.
>
> Comments/discussions/suggestions are encouraged and welcome.
>
> Tack Tong
> IBM Rational software
> tacktong at ca.ibm.com
> 905-413-3232
> tie line 313-3232
>
> _______________________________________________
> Oslc-Reporting mailing list
> Oslc-Reporting at open-services.net
> http://open-services.net/mailman/listinfo/oslc-reporting_open-services.net
>
>