[hibernate-dev] 6.0 - concept naming

[andrea boriero]

I lean to your 3th option

On 3 May 2017 at 15:01, Steve Ebersole <steve at hibernate.org> 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 <steve at hibernate.org>
> wrote:
>
> > On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <
> > 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".
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>