> The problem with this is that if you have an inheritance > hierarchy in which your outermost descendant(s) extend several fields, > you've loaded your base entities with a mass of irrelevant fields > containing an unusual <missing> (i've never seen that before).
I'm pretty sure that the base entities (the things in the datastore) don't have those fields. The "missing" message comes from a tool that is looking at instances pulled from the datastore. It expects to see things and when it doesn't, it says <missing>. > if you are building an application that, say for example, reads the > fields (columns?) in the entity for display to the user (like the > Dashboard's Data Viewer), you end up presenting irrelevant fields. That happens only if your application doesn't understand polymodels. I'm still working through the details because "not polymodels" don't support class_name() and polymodels don't support anything like db.class_for_kind(). However, properties() appears to do the right thing. One good reason for implementing Polymodels with a single entity type is that implementing them with multiple entity types would make queries a lot more expensive. If polymodels were implemented with multiple entity types, each application-level query would need to make multiple datastore queries, one for each applicable datastore entity type. If those queries are done in the datastore (as with "in" queries), the datastore needs to know some things that it doesn't currently know and the "30 datastore queries per application query" limit comes into play. If those queries are done in the application run time, limits (and maybe transactions) will behave differently. I think that __key__ can be made to work across multiple entity types, but wouldn't be surprised if implementing PolyModel with multiple multiple entity types raised issues there as well. BTW - entity groups for transaction purposes have nothing to do with entity types or polymodels. They're really entity instance groups because they are defined wrt key name hierarchies. On Mar 27, 11:54 pm, Rein Petersen <rein.peter...@gmail.com> wrote: > Hi, > > At risk of sounding too critical (believe me - i am so very > appreciative of GAE), something about PolyModel has been bothering me > enough that i must get it off my chest in the hope that it might be > reworked. The PolyModel was created to allow developers to access all > child entities through the base. i think it is an important ability > for the GAE and PolyModel addresses the need. > > But, (here it comes) every extension (field) is stored in the same > table? (entity group) along with an extra field (list) that stores the > class names. The problem with this is that if you have an inheritance > hierarchy in which your outermost descendant(s) extend several fields, > you've loaded your base entities with a mass of irrelevant fields > containing an unusual <missing> (i've never seen that before). > > if you are building an application that, say for example, reads the > fields (columns?) in the entity for display to the user (like the > Dashboard's Data Viewer), you end up presenting irrelevant fields. How > the unnecessary fetching of these extension fields affects performance > i cannot say but i would guess it is not helpful. > > i tend to think that each subclass entity justifies its own distinct > table? / entity ? and would only contain the fields which extend it's > base class which resides in the same entity group as the parent. > > PolyModel could then, instead, walk the parent chain adding fields as > necessary until it reaches the root entity. The subclassed entity > would be presented as a composite of all the fields within itself and > it's ascendants. since the superclass entities are assigned to the > subclass entities by parent, the reside in the same entity group and > shouldn't be an impediment to scalability or within a transaction > > it seems to make so much sense to me that i can only guess there was > some obstacle preventing it being so and the only solution was what we > have now. if that is the case, please tell me so i can just give up on > this... otherwise comments are always welcome - > > thanks :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
