Re: proposal on ISSUE-94 ("lossless paging")

Sandro wrote:
> PROPOSED: Change LDP paging to no longer be characterized as
> "lossy". Specifically, a client who pages all the way through
> (forward or backward) MUST be sent every triple in intersect
> (g0, g1, ... gn) and MAY be sent any triples in the union (g0,
> g1,  .. gn), where Gi is the paged graph at the time client
> makes request i.  Servers MAY refuse to serve any page because
> they don't want to implement this kind of paging in certain
> cases; if they do so, they MUST return a 410 GONE.


I think Sandro's suggestion remains “lossy", in that insertions 
*may* be made visible, but any deletions are to be concealed.
This bothers me.

As I said in the con-call, I think the current paging thoughts
are a conflation of two concepts from the (R)DBMS world - 
“(scrollable) cursors” and “(transaction) isolation”. 

I strongly recommend some investigation of these concepts.  
These wikipedia pages are imperfect but provide a good, if 
basic, starting point.

   <https://en.wikipedia.org/wiki/Isolation_%28database_systems%29>

   <https://en.wikipedia.org/wiki/Cursor_%28databases%29>

I recommend particular attention to the “Isolation Levels vs 
Read Phenomena” table on the Isolation page.

There are tradeoffs to each and every option — and whether any 
given tradeoff is more or less important depends on the use case —
and this is why the DBMS world mostly sees every engine implement
all cursors and isolation levels, and mostly allows clients to 
specify which ones they want/need to use.

I would suggest that we consider writing this version of the 
LDP spec to only require implementation of the lowest-level, 
least-effort options in each.

For the cursor, this is the “FORWARD ONLY” a/k/a “non-scrollable” 
cursor.  The scroll only goes from one end to the other, without 
any reversing midway.  When working with an unORDERed result set, 
you can only go in the arbitrary “forward”  direction.  When 
working with an ORDERed result set, it is really “unidirectionally 
scrollable” because it can be walked in either direction by simply 
inverting the ORDER BY.

For isolation, this is “READ UNCOMMITTED”, which basically means
that the client can’t rely on anything being the same *now* as it
was *then*, no matter how short the window between.  The client
gets a snapshot-in-time for each request, but has no way to tell 
the server “act on *that* snapshot-in-time” nor how to act based
on *other* client requests received in the interim (or received 
after mine, but based on the same state as my request was...)

I think this leaves a clear path for future evolution (adding
the other cursors and/or isolation levels), while making the 
current spec easier to write and early implementations easier 
to produce.

I hope this is more helpful than painful.

Ted




--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers

Received on Monday, 24 March 2014 16:45:13 UTC