Hmm.. well, to explicitly support a query like this as is.. you'll have to wait for Alfred's next gen zigzag-sort query to come out.
Naturally, there are all sorts of convoluted solutions... that may or may not be helpful.. depending on your specific situation. If Entries is not "too large", you could have an offline process run every N minutes to generate three "materialized view"-like versions of the table.. with the appropriate sort property pre-pended to the front of the key_name. Depending on how many different distinct queries are executed against Entries, you could execute the query, sort in memory and then store the results in the appropriate order in an EntriesQuery model with a key_name = QueryHash + '_' + ZeroPaddedOrderID. And, then just have your application code update those query results on demand.. if N minutes have passed since the last update. etc, etc, and so on. On Wed, Jan 12, 2011 at 2:22 PM, Bill Edwards <[email protected]> wrote: > Hi Eli, > > Thanks for your input. This is a clever solution to the case I > brought up. However, this actually won't work for me, because I > actually need to accomodate for three different queries, each with a > different sort order. > > On Jan 12, 8:05 am, Eli Jones <[email protected]> wrote: > > If the key_name for Entries doesn't need to be static.. and the stat1 > value > > does not change "very often".. and you don't depend on > .get_by_key_name().. > > I believe you could just prepend a zero padded version of stat1 to the > > Entries key_name like so: > > > > new_key_name = stat1.rjust(10,'0') + '_' + old_key_name > > > > Then you should be able to do queries like: > > > > Select * From Entries Where campaigns = :1 AND stat3_categories = :2 AND > > owners_saved = :3 Order By __key__ > > > > I have left out the details of exactly how you will determine what base > > key_name to use when an Entity is first created. > > > > I have also left out the details of how you will handle the changing of > the > > key_name whenever stat1 changes. (I'd guess just do it in a transaction) > > > > I also do not know if this works on ListProperties.. I only know that you > > can use it with regular single valued properties.. to get sorting "for > free" > > without needing to create a compound index. (I have an entity model that > > does not change after it is created.. so I just make the __key__ begin > with > > a zero padded version of whatever I want to sort by.) > > > > > > > > > > > > > > > > On Tue, Jan 11, 2011 at 9:34 PM, Bill Edwards <[email protected]> > wrote: > > > I recently watched a Google I/O Talk regarding exploding indexes, and > > > realized that the application that I am currently developing has > > > queries that are susceptible to this problem. Try as I might, I can't > > > think of a good way to resolve my problem, so I was hoping to get some > > > input. > > > > > My database model is as follows: > > > > > class Entries(db.Model): > > > campaigns = db.ListProperty(db.Key) > > > owners = db.ListProperty(db.Key) > > > owners_saved = db.ListProperty(db.Key) > > > owners_unsaved = db.ListProperty(db.Key) > > > parent_entries = db.StringListProperty() > > > entry = db.StringProperty() > > > stat1 = db.IntegerProperty(default = 0) > > > stat2 = db.FloatProperty() > > > stat3 = db.FloatProperty() > > > stat3_categories= db.StringListProperty() > > > > > I am attempting to do queries such as: > > > SELECT * FROM Entries WHERE campaigns=:1 and stat3_categories=:2 and > > > owners_saved=:3 ORDER BY stat1 > > > > > The problem is rooted in the fact that length of the campaigns and > > > owners_saved list can potentially grow into the hundreds and > > > stat3_categories can be up to 40 elements long. > > > > > I have read other threads in relation to solutions for this problem. > > > One solution that comes up is to remove the sort from the query. > > > However, each query results in thousands of results, and I am only > > > retrieving 10 at a time (and displaying the results in paged format). > > > > > Are there other ideas on how to resolve this type of exploding index > > > issue? > > > > > -- > > > 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]<google-appengine%[email protected]><google-appengine%2Bunsubscrib > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine?hl=en. > > -- > 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]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- 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.
