I'm asking if it's wise to store it as a query parameter embedded in a web page.
On Feb 9, 12:26 am, "Ikai L (Google)" <[email protected]> wrote: > A cursor serializes to a Base64 encoded String, so you can store it anywhere > you want to store strings: Memcached, Datastore, etc. You can even pass it > as an URL parameter to task queues. > > 2010/2/8 Stephen <[email protected]> > > > > > > > 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]> > > <google-appengine%[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]> > > <google-appengine%[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]<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.
