I was unclear. I meant that using an order by with an explicit ASC together with the WHERE clause resulted in a custom index, just like the query with an implicit ASC and the WHERE clause. (I think that the two should behave exactly the same but it's always good to verify.)
Thanks for the explanation. Perhaps a sentence indicating that an ascending sort order with another property or ancestor filter will result in a custom filter could be added to the list of examples. Or, maybe a phrase pointing out queries that combine features usually require an index can be added to the description. On Oct 10, 6:58 pm, ryan <[EMAIL PROTECTED]> wrote: > hi andy! the queries described that don't need indices are disjoint. > queries that combine features from more than one of them will usually > still need an index. > > in your case, WHERE user = :user ORDER BY created_at has both an > equals filter *and* a sort order, so it needs an index. > > in general, all queries that involve multiple properties or an > ancestor will need indices, except if all properties are only used in > equals filters and there are no sort orders. > > as for the ORDER BY created_at ASC query, i ran that query > inhttp://shell.appspot.com/, running in a local dev_appserver - code > below - and it didn't generate an index in index.yaml for me. > > >>> class Foo(db.Model): > pass > >>> print list(Foo.gql('ORDER BY created_at ASC')) > > [] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
