Personally I think it is maybe better to getting it working first the way the persisters expect it currently. Addressing changes inside the persister is a next step, but I did not want to "dirty the waters" in terms of trying to implement this new metamodel while both the producers and consumers are in flux (one in flux at a time is enough in my original estimation).
Just my $.02 On 12/06/2012 10:37 AM, Strong Liu wrote: > having a design question, how should we model this > > (correct me if I get this wrong) > for this inheritance hierarchy, the relational model of root entity is pushed > to the sub entity, so the table of sub entity has all "root table" columns / > pk > and depends on if root entity is abstract, there may or may not having a > physical table for the root entity > > > we used this org.hibernate.mapping.DenormalizedTable to model a union > subclass table, and also the Table class has a > org.hibernate.mapping.Table#isPhysicalTable to tell schema tool if this table > should be created or not > > > For the new Metamodel, as Gail and I discussed, we don't want to have some > fake table even for the abstract root entity, NULL for the return value of > EntityBinding.getPrimaryTable() is better and clean design. > > but on the other hand, the DenormalizedTable design is quite simple to impl > in the Binder ( I already get it works ), esp considering we bind root entity > first and don't have second pass. > > > wdyt? > > ------------------------- > Best Regards, > > Strong Liu <stliu at hibernate.org> > http://about.me/stliu/bio > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
