You appear to be talking about two different things here: JDO ORM specs & GAEJ's JDO support. I'll take each one independently.
1. JDO ORM Specification If you're referring to JDO, the specification, as distinct from GAEJ's DataNucleus plugin for BigTable, then you are referring to the object-relational features of the specification. I can assure you (as a member of the JDO expert group) that the inheritance mapping that you are describing here is fully supported. It's commonly known as table-per-hierarchy, and JDO supports it. See section 15.7 (p.209) of the JDO 3.0 specification (available via http://db.apache.org/jdo/specifications.html and quoted below). You would just specify new-table for the base class's inheritance mapping and superclass-table for each subclass's inheritance mappings. In fact, (JDO 2.0 & later) standardizes many different inheritance mapping strategies, including not only table-per-hierarchy, table-per-class & table-per-concrete-class, but also any mix thereof. >From the specification: <quotation> 15.7 Inheritance Each class can declare an inheritance strategy. Three strategies are supported by standard metadata: new-table, superclass-table, and subclass-table. • new-table creates a new table for the fields of the class. • superclass-table maps the fields of the class into the superclass table. • subclass-table forces subclasses to map the fields of the class to their own table. Using these strategies, standard metadata directly supports several common inheritance patterns, as well as combinations of these patterns within a single inheritance hierarchy. One common pattern uses one table for an entire inheritance hierarchy. A column called the discriminator column is used to determine to which class each row belongs. This pattern is achieved by a strategy of new-table for the base class, and superclass-table for all subclasses. These are the default strategies for base classes and subclasses when no explicit strategy is given. Another pattern uses multiple tables joined by their primary keys. In this pattern, the existence of a row in a table determines the class of the row. A discriminator column is not required, but may be used to increase the efficiency of certain operations. This pattern is achieved by a strategy of newtable for the base class, and new-table for all subclasses. In this case, the join element specifies the columns to be used for associating the columns in the table mapped by the subclass(es) and the table mapped by the superclass. A third pattern maps fields of superclasses and subclasses into subclass tables. This pattern is achieved by a strategy of subclass-table for the base class, and new-table for direct subclasses. </quotation> There are no restrictions placed on how a class specifies its inheritance mapping. While I do not advocate deep inheritance hierarchies, but the top 3 classes of a hierarchy could be mapped to one table, the next 2 classes can be to their own tables, and anything below that to another single table. Really it's up to you and how your app uses the object graph -- its performance usually varies as a function of how its used and how its inheritance is mapped. 2. GAEJ's JDO support This is where I was a little bit surprised as I read through your example. You are discussing mapping features that I don't believe apply to Google's BigTable-based persistence, unless I'm missing something. BigTable focuses on entities and entity groups, which are a different beast than relational tables. In fact, whereas tables and their structure maps to classes, BigTable's schema seems to be more focused on the objects than the classes. While I don't have any real production experience using BigTable, that is my understanding. Someone please correct me if I'm wrong about that. So, which use of JDO were you referring to? JDO-standardized ORM or JDO/GAEJ/DN/BigTable? -matthew On Fri, Jan 7, 2011 at 6:32 PM, John Bito <[email protected]> wrote: > > On Thu, Jan 6, 2011 at 20:26, Matthew Adams <[email protected]> wrote: >> >> Can you expain what you mean by this? >> >> > Among the more annoying limitations in JDO is the prohibition of >> > superclass-table inheritance. >> >> I'd like to understand it. > > The case for a superclass-table inheritance is relevant where the app has a > series of subclasses with differing behaviors but (mostly) the same > properties. One example might be classes of display assets, such as > > virtual class Asset { > Key id; > Key collection; > URI location; > virtual String displayMarkup(); > } > > class Image extends Asset { > String displayMarkup() { > return MarkupBuilder.generateImg(location); > } > } > > class Video extends Asset { > String displayMarkup() { > return MarkupBuilder.generateObject(location); > } > } > > Most persistence providers that I've used will allow the Asset class to > provide 'superclass-table' persistence which means all the Video and Image > instances persist in the Asset table. A key benefit here is that it's > efficient to retrieve all the instances of Asset that belong to a collection > (each instance will be either an Image or Video). It also makes it much > simpler to form queries, particularly since the GAE datastore doesn't allow > joins. > > -- mailto:[email protected] skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:[email protected] msn:[email protected] http://matthewadams.me http://www.linkedin.com/in/matthewadams -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
