Option 3. On 05/03/2017 10:01 AM, Steve Ebersole wrote: > To circle back to this... I mentioned possibly keeping a reference to the > foreign-key defining the join predicate between the root table and the > secondary table. ATM however we do not model FKs in the runtime > metamodel (either in 6 or before). So that will not work unless we start > to do that. > > Another possibility is to simply keep the list of columns from the > secondary table that are used in the join predicate. This would work > because of an explicit rule followed by both Hibernate and JPA - namely > that secondary tables (and joined inheritance tables btw) join back to the > PK columns of the root table. In other words, we implicitly know the "left > hand side" portion of the join predicate. > > So we have 3 options total for modeling this join predicate: > > 1. Maintain a predicate tree as part of this SecondaryTableBinding. ATM > we have no such concept of this either in the runtime metamodel, so we > would need to add this if we choose this option. This would mean adding > the concept of conjunction/disjunction and relational-operators in some > form to the runtime metamodel. Personally, this is my least favorite > option. > 2. Maintain the join predicate on SecondaryTableBinding via a FK > reference. Again, this would mean adding a new concept/class to model the > FK as part of the runtime metamodel. I am not against this option so long > as we deem it has similar benefits in other parts of the codebase - I'd > prefer to not add such a concept just to handle this case. > 3. Follow the assumption regarding the "left hand side" of these joins > and just keep a list of the columns from the secondary table that link to > the entity's root table's PK columns. > > > FWIW, both Hibernate and JPA also assume that the same holds true for > joined inheritance tables. Whatever we decide here for secondary tables, > we should apply to modeling joined inheritence for consistency - perhaps > even to the point of a shared contract (NonRootTableBinding?). > > Opinions? > > On Wed, Apr 19, 2017 at 8:35 AM Steve Ebersole <st...@hibernate.org> wrote: > >> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov < >> christian.bei...@gmail.com> wrote: >> >>> Sounds good. I hope the secondary table stuff is getting defined on a >>> higher level(EntityPersister/AbstractEntityPersister). I had problems >>> implementing OneToOne-JoinTable support for >>> TablePerClass(UnionSubclassPersister) a while ago and I guess that was >>> because there is no notion of secondary tables in the EntityPersister. I >>> guess that issue would be solved then? :) >>> >> Not sure what you mean by "higher level". The design here specifically >> shows secondary tables modeled as top-level concepts ( >> SecondaryTableBinding). So I think, again iiuc, that the design already >> shows secondary tables "defined on a higher level". >> > _______________________________________________ > 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
