I am wrestling with the very same problem, Abel. I don't have a good
answer just yet.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@g
I gave up and just went with paging through 1000 results and figure
people shouldn't have to go back further. That's a reality for the
application I'm working on, but not one for others I'm sure.
Besides the "if something is deleted" problem, I also found it
problematic to try and page for things
So far, I haven't had to deal with problem of paging through more than
a couple dozen items, so I'm just grabbing them all and then slicing
the results to get what I need. It's ugly and doesn't scale at all,
but it is all that I have been able to come up with. I'm glad that
I'm not the only one
I use Brett Slatkin's technique: in the model I page over, I have a
string property called "order". It's a composite string and it's
guarantied to be unique.
When querying for entities, I ORDER BY this property. If I want to
have 20 entities per page, I fetch 21 entities, show 20 of them and
use
You could achieve a back button by using a similar scheme (selecting
pageSize+1) and ordering descending.
eg, Say you had an index field with entries "index1", "index2", etc.
Gaps would be fine (but assume none in this example). Say the page
size is 10.
First page you just select the first
best way i found is to use any entity and +1 rule. and back link using
HTTP REFERER (not accurate but reliable in most conditions..)
On Nov 19, 9:38 pm, "Abel Rodriguez" <[EMAIL PROTECTED]> wrote:
> I am currently doing a detailed study on how to optimize my
> application to be scalable.
>
> I ha
> The only downside is that it's not possible to page back
> HTTP REFERER (not accurate but reliable in most conditions..)
Couldn't you build a paging index incrementally, and put it in a
cookie?
--~--~-~--~~~---~--~~
You received this message because you are su
I plan to do this by building an index entity as entries are added.
So, for example, the index entity would contain the order string for
every 10th entry (the first on each page), allowing you to jump
straight to a particular page.
On Nov 20, 11:07 am, Jon Watte <[EMAIL PROTECTED]> wrote:
> > The
> You could achieve a back button by using a similar scheme (selecting
> pageSize+1) and ordering descending.
Thanks Michael, I'll give it a try!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engine" gr
> best way i found is to use any entity and +1 rule. and back link using
> HTTP REFERER (not accurate but reliable in most conditions..)
The referrer will point to the wrong page once the user clicks the
back link.
--~--~-~--~~~---~--~~
You received this message be
I just started using this class in my blog software. It requires two
queries, one to get the main page of results plus the index of the
next page and one to get the index of the previous page. Since it
requires two queries per request, you definitely want to use memcache
to save the results. It
If anyone cares, I just made a big post on my blog about this code and
a particular use case. Also, you can see the code in action, as it
was extracted from my blogging software, which runs on AppEngine:
http://blog.adamcrossland.net/showpost?id=aglhZGFtY2Jsb2dyLQsSCUJsb2dJbmRleCIJYWRhbWNibG9nDA
It's possible to achieve the same result by maintaining a general
index of all the items of the same class. The index would be a list,
which could be massive and takes times to be loaded but if memcached,
would not be that impressive to use. Using a list would enable you: 1)
to sort items by a spe
13 matches
Mail list logo
