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]> > . > 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.
