On Apr 18, 3:57 pm, Jaroslav Záruba <[email protected]> wrote:
> The "set of pages" is a little bit confusing for me. Do you mean "current, > next and previous set of *records*"? (I.e. records to be displayed > on current/next/previous page.) > > I was thinking about using memcache for paging (of articles) too, I did not > think about using cursors though, as I have only very shallow experience > with them. I have to look at them, this sounds promising. > See, with cursors, you can do basic pagination of entries (not the content of the entries themselves. Like if you have 200 entries in the datastore for an entity type, you can show 10 at a time and using the cursor, you can generate a "next" link. But that in turn poses a problem: you can only generate a "next" link, and not "previous" link. So my idea for the solution is to go over the remaining results in a quick way, and cache the cursors that point to first page, second page and so on.. in a csv in memcache entry(session managed, of course). Now using this memcache entry, you can generate a whole array of page links. The next problem that arises is that if the database has grown too big, then the csv generation will be slow(as it has to jump a lot of times). So the next idea is , instead of generating all cursors in the main cgi , the main cgi generates only first few set of page links, and then triggers a task queue entry to continue from there. By the time the user would have read the first page and clicks on "next page", the task would have generated few more entries. As the set of cursors for pagination is in memcache, you can use it even in your first page, if you are using AJAX (guessing, not that sure.) -- 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.
