On Tue, Sep 25, 2012 at 1:12 AM, Moises Belchin <[email protected]> wrote: > Hi Guido, > > Thanks for your comments and help. > > I think adding sort order by key is a problem. For example: > > If you have a kind on which you have equals filters using fetch with limit, > offset you don't need to use indexes. However if you use fetch_page, you > need to create indexes for q_desc. If you have a big app and use indexes for > any kind you'll quickly consume your index quotas.
OTOH the cost of using offset is not zero either -- you pay as much for the skipped entities as for the results. > In addition, this result, > > [1, 2, 3] > [4, 5, 6] > [6, 5, 4] > [3, 2, 1] > > for me is not correct. > > I think if you show a grid to an user (1,2,3), the user clicks on next > button and he views (4,5,6). Then If the user now clicks on previous button > the user must view (1,2,3) instead of (3,2,1). > > Now I you use fetch with offset and limit you get this behaviour(1,2,3)-> > (4,5,6) <- (1,2,3), however with fetch_page and reversed cursor this not. If you want to display the results as [3, 2, 1] just reverse the results list in memory. [...].reverse() does the job in-line in O(N) time with o extra space needed. > I think, one option may be use fetch_page with positive or negative limit to > simulate this behaviour. I don't know If this can be correct. If you're proposing a feature change, underneath the implementation would have to do all the same work. Consider fetch_page() a building block that makes it possible to do the right thing, not necessarily the most convenient thing (which would depend on the needs of a particular app). > Thanks for your time and for heard me. > Regards. > Moisés Belchín. > > > > 2012/9/24 Guido van Rossum <[email protected]> >> >> Hi Moises, >> >> I think you may be able to solve this by adding a sort order by key, as >> follows: >> >> q_next = q.order(MaqHistMov.idsm, MaqHistMov.key) >> q_previous = q.order(-MaqHistMov.idsm, -MaqHistMov.key) >> >> FWIW, here is an example that I think represents what you are doing: >> >> class M(ndb.Model): >> a = ndb.IntegerProperty() >> b = ndb.IntegerProperty() >> M(a=1, b=1).put() >> M(a=2, b=1).put() >> M(a=3, b=1).put() >> M(a=4, b=2).put() >> M(a=5, b=3).put() >> M(a=6, b=4).put() >> q = M.query() >> q_asc = q.order(M.b, M.key) >> q_desc = q.order(-M.b, -M.key) >> r1, c1, m1 = q_asc.fetch_page(3) >> print [r.a for r in r1] >> r2, c2, m2 = q_asc.fetch_page(3, start_cursor=c1) >> print [r.a for r in r2] >> r3, c3, m3 = q_desc.fetch_page(3, start_cursor=c2.reversed()) >> print [r.a for r in r3] >> r4, c4, m4 = q_desc.fetch_page(3, start_cursor=c3) >> print [r.a for r in r4] >> >> This outputs the following for me, which I think is correct: >> >> [1, 2, 3] >> [4, 5, 6] >> [6, 5, 4] >> [3, 2, 1] >> >> Note that the final query does not reverse the cursor, since its start >> cursor is already reversed. So you only reverse the cursor upon >> reversing query directions. >> >> --Guido >> >> On Mon, Sep 24, 2012 at 4:12 AM, Moises Belchin <[email protected]> >> wrote: >> > Hi Guido, >> > >> > Thanks in advance to take your time and figure out our problem. >> > >> > I send you the code we're using and an image to show you our model and >> > some >> > entities to review our query results. >> > >> > The first problem we encountered is that idsm property must be indexed >> > if >> > you want to order by MaqHistMov.idsm desc. If you use limit, offset >> > query >> > fetch this requirement doesn't exist. >> >> -- >> --Guido van Rossum (python.org/~guido) > > -- --Guido van Rossum (python.org/~guido) -- 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.
