[hibernate-dev] 6.0 - concept naming

[Christian Beikov]

Hehe too fast, I meant option 3. :D


Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 03.05.2017 um 16:01 schrieb Steve Ebersole:
> 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 at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov
>     <christian.beikov at gmail.com <mailto:christian.beikov at 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".
>