The easiest option I can suggest is to use memcache to store the
'bookmarks' for the beginning of each page. If the user wants the 5th
page, for example, you can look in memcache for the '5th page'
bookmark (which is a tuple (score, key) for the first entity that
should appear on the page, or the last entity that shouldn't. If your
score is unique, you can skip the key component). If you don't find
the bookmark, page back until you find one and generate results from
there, storing the changed details.
Then, whenever you modify something that will affect the sorting
order, you can either invalidate all the bookmarks, or figure out
which ones it will affect and delete or update those.
As far as generating unique scores, I would advise _against_
converting to a float. With a timestamp, you can easily create a
monotonic counter by incrementing it until it's unique, but with a
float, there's no way to reliably know what the minimum amount you can
increment by is.
On Dec 10, 2:58 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> The primary reason I'd like the specific page number capability is for
> the format I'm going with, it's something users expect to see. Though,
> currently it looks like this is not going to be a possibility. The
> primary purpose is a user may want to go back several pages just to
> see what's there.
>
> I did see the other thread, that's what I've been working off of for
> my solution. Currently I'm switching my scores from integers to floats
> in order to make sure I can easily make each one unique. Scores are
> actually timestamps (in unix seconds) so by switching to a float I can
> add .001 to create unique instances.
>
> Using the caching library from gaeutilities, I plan to get the
> previous links working correctly also. The design is
>
> Request for list of stories with an option start index is made.
> Check cache for a list with that start index, return if it exists.
> Otherwise
> Fetch 11 stories using the index as a starting point.
> Popular a dictionary with something like
> {'next': results[-1].score,
> 'prev': results[0].score
> 'stories': results 0-9 }
> Cache and return it.
>
> End result is the cache keeps the previous and next indexes making it
> so you can page forward and backwards.
>
> If a story is added, or the order changes, delete all the cache
> entries.
>
> On Dec 10, 2:06 am, Michael Hart <[EMAIL PROTECTED]> wrote:
>
> > Out of interest, why is it a requirement that you can page to any
> > arbitrary page? How would a user know that they want to go to page 5
> > specifically?
>
> > How about just letting them go to a page in the next/prev n pages,
> > where n is, say, 3 - as well as the last and first pages.
>
> > More on this here (although you've probably seen it):
>
> >http://groups.google.com/group/google-appengine/browse_thread/thread/...
>
> > On 10/12/2008, at 6:26 AM, [EMAIL PROTECTED] wrote:
>
> > > I tried a sledgehammer approach to a paging issue I'm having (fetch
> > > (1000) page within it) and as expected, it's too heavy of an approach
> > > and I'm getting datastore timeouts. So, before I dive too deeply into
> > > approaching the situation I have, I thought I'd see if anyone else has
> > > run into this and came up with a solution they'd like to share.
>
> > > The requirements I have are:
> > > - Must be able to page through entities based on a numerical score
> > > field that is not consecutive, though can be made unique if I convert
> > > it to a float.
> > > - Previous, Next, and ?page=# (ie: ?page=5) must all be handled.
>
> > > The situation is that I'm working on a site that's similar to Digg in
> > > functionality. Stories are given a score by which they are ordered for
> > > presentation. This score can change through user interaction.
>
> > > Now, I have already ready and figured out a solution for next/previous
>
> > > results = fetch(11)
> > > ?nextstart=results[10].score&prevstart=results[0].score
>
> > > This doesn't give me the ability to link to specific pages. As scores
> > > are changing and new entities can be created a rapid rate (bursts once
> > > an hour of 50+ entities) trying to index and keep track on submission/
> > > score change would also lead to datastore timeouts.
>
> > > Anyone have any ideas? I'm beginning to think I just can not meet the
> > > page number requirement using BigTable.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
