Thanks for your thoughtful response, Matthew. My disapointment is with the lack of support for superclass-table in the GAE/J implementation of mapping for JDO. I haven't thought deeply enough to have a strong feeling for the difficulties that could be introduced by an implementation that stored instances of subclasses in one entity kind, but previous discussions including Max Ross left me with the feeling that it was mostly a question of incremental effort rather than an major architectural concern.
Of course, my previous experience with JDO/JPA in ORM scenarios may be leading to a bias in my thinking. Much of the persistent model in my application is working well (so far) with an agnostic set of annotations; it could run on a relational DB. If the JDO mapping for the GAE datastore included support for superclass-table, I'd feel that I could define a more efficient model that would also allow my to write queries more simply. Best Regards, John On Fri, Jan 7, 2011 at 16:57, Matthew Adams <matt...@matthewadams.me> wrote: > 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 <jwb...@gmail.com> wrote: > > > > On Thu, Jan 6, 2011 at 20:26, Matthew Adams <matt...@matthewadams.me> > 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:matt...@matthewadams.me > skype:matthewadams12 > yahoo:matthewadams > aol:matthewadams12 > google-talk:matthewadam...@gmail.com<google-talk%3amatthewadam...@gmail.com> > msn:matt...@matthewadams.me <msn%3amatt...@matthewadams.me> > 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 google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
