Re: [hibernate-dev] 6.0 - concept naming

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 <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote: On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <christian.beikov(a)gmail.com <mailto:christian.beikov@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".