This is not the main reason why i chose to go with expando objects, but it does a little like this:
In expando's, I can store just information i need; that is, if I happen to have a 'color' attribute for a given entry, I can just store it's 'color' information even if others dont have it; Also, in expando's I can store list of lists by using setattr(self, property, listoflist). Model objects seem to not like the explicit setting of ListProperty(list). but maybe I got this backwards. any input would be appreciated. (ps, im rewritting the core portion of this anyway, as there is no obvious scalable workaround for my indexing problem. I will just have to choose a list of commonly used properties and build indexes against those, and dump everything else in a single predefined property (and index that one as well), as to never raise an index not found error in production). On Feb 21, 10:35 pm, bd_ <bdon...@gmail.com> wrote: > On Feb 20, 3:13 pm, pedepy <paul.ro...@gmail.com> wrote: > > > Hi .. I just stumbed upon a NeedIndexError. I understand why it > > happens, but I dont quite understand the 'motivations' behind it. > > > If the development server can just generate indexes for queries as I > > make them, why would that not be possible for the deployed app? My app > > makes extensive use of Expando objects who's properties I cannot fully > > predict. As such, the combination of all possible queries is also > > almost possible to determine before hand. > > The development server does not generate indexes, actually. Whenever > you do a query, it loops over every item in the datastore, filtering > for those that match your query. Obviously, this scales rather badly, > but on the plus side, dealing with a query that would otherwise use a > new index is trivial :) > > Actually generating a new index requires sorting every item of the > model in question and building an index out of that. As Dan points > out, that can be a very expensive operation, and moreover ongoing > costs for inserts/updates should be a concern. > > Since you've not given any details about /why/ you're using Expando > objects, all I can say is that you'll have to get clever with one or > two special properties to manufacture whatever queries you want. --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---