Ah right, Nick's blog does say start_key and not offset. My bad.
Maybe there will be warnings in the upcoming documentation, but my
first instinct was to embed the serialised cursor in the HTML as the
'next' link. But that doesn't look like a good idea as Nick's decoded
query shows what's embedded:
PrimaryScan {
start_key: "shell\000TestModel\000foo\000\232bar\000\200"
start_inclusive: true
}
keys_only: false
First, you may or may not want to leak this info. Second, could this
be altered on the client to change the query in any way that's
undesirable?
Once you have a cursor, where do you store it so you can use it again?
On Feb 8, 10:17 pm, "Ikai L (Google)" <[email protected]> wrote:
> I got beaten to this answer. No, there is no traversal to get to the offset.
>
> BigTable has an underlying mechanism for range queries on keys. Indexes are
> essentially a key comprised of a concatenation of application ID, entity
> type, column, value. When a filter operation is performed, the datastore
> looks for a range matching this criteria, returning the set of keys. A
> cursor also adds the datastore key of the entity so it is possible to
> serialize where to begin the query. This is actually a bit awkward to
> explain without visuals. You can watch Ryan Barrett's talk here:
>
> http://www.youtube.com/watch?v=tx5gdoNpcZM
>
> Hopefully, we'll be able to post an article at some point in the future
> explaining how cursors work.
>
> 2010/2/8 Alkis Evlogimenos ('Αλκης Ευλογημένος) <[email protected]>
>
>
>
> > There is no offset. The protocol buffer stores a start_key and a boolean
> > denoting if this start key is inclusive or not. The performance of
> > continuing the fetch from a cursor should be the same as the performance of
> > the first entities you got from a query.
>
> > On Mon, Feb 8, 2010 at 4:33 PM, Stephen <[email protected]> wrote:
>
> >> On Feb 8, 7:06 pm, "Ikai L (Google)" <[email protected]> wrote:
> >> > The official docs are pending, but here's Nick Johnson to the rescue:
>
> >> >http://blog.notdot.net/2010/02/New-features-in-1-3-1-prerelease-Cursors
>
> >> What are the performance characteristics of cursors?
>
> >> The serialised cursor shows that it stores an offset. Does that mean
> >> that if the offset is one million, one million rows will have to be
> >> skipped before the next 10 are returned? This will be faster than
> >> doing it in your app, but not as quick as the existing bookmark
> >> techniques which use the primary key index.
>
> >> Or is the server-side stateful, like a typical SQL implementation of
> >> cursors? In which case, are there any limits to the number of active
> >> cursors? Or what if a cursor is resumed some time in the future; will
> >> it work at all, or work slower?
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Google App Engine" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected]<google-appengine%[email protected]>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/google-appengine?hl=en.
>
> > --
>
> > Alkis
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<google-appengine%[email protected]>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-appengine?hl=en.
>
> --
> Ikai Lan
> Developer Programs Engineer, Google App
> Enginehttp://googleappengine.blogspot.com|http://twitter.com/app_engine
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
