paging using cursor or offset ?

2,261 views
Skip to first unread message

Luke

unread,
Feb 26, 2011, 2:57:00 AM2/26/11
to objectify-appengine
paging using cursor or offset ?

1. i read http://code.google.com/p/objectify-appengine/wiki/IntroductionToObjectify#Cursors
, in order to use cursor, after getting list of result with Query,
there is a need to iterate through the list and get the last cursor
for the last element in the list? what if i only need the get the
list result and pass to client-side javascript? can iterate to get the
last cursor be done on client-side javascript?

2. aren't using offset+limit is much more earsier compared to cursor.
i do not need to keep record of last cursor (position) i on. the
query will still return correct "ordering" same result right if if do
same Query(..) but with different offset+limit ?


3. what is the advantages of using cursor

Jeff Schnitzer

unread,
Feb 26, 2011, 11:37:31 AM2/26/11
to objectify...@googlegroups.com
The short version:

Cursors are like a pointer to a specific place in a query. When you
create a query with a cursor, the backend starts at exactly the object
you specified - even if subsequent changes to the datastore added or
removed entities to earlier parts of the query.

Offset is just what it sounds like. GAE will start the query and
iterate through the results for the specified offfset. This has
performance implications (large offsets are expensive) and means the
query results will change if entities early on are added/removed.

You cannot make datastore calls from the client side, except through
RPCs that you provide. That question expresses a fundamental
conceptual misunderstanding of how GWT works - please re-read the
basic GWT docs.

Jeff

scorpion

unread,
Feb 27, 2011, 5:50:25 AM2/27/11
to objectify-appengine
What is the memory impact because of use of cursors. I can think of 2
possible ways cursors are implemented -
1. The result of the entire query is cached (preferable keys) and the
cursor is held such that it points somewhere in the collection of this
query or
2. The cursor is maintained at some key (keys are indexed and sorted,
I hope). So when the next cursor request comes in, the query is
executed only on those keys which are lexicographically greater than
the cursor's orginal position.

Now scalability with 1. is poor, while integrity if 2. could be
doubtful.
Which approach is chosen for cursor implementation or is there a third
approach?

Jeff Schnitzer

unread,
Feb 27, 2011, 1:19:29 PM2/27/11
to objectify...@googlegroups.com
Cursors operate almost exactly as described in #2.

Jeff

Reply all
Reply to author
Forward
0 new messages