the proposal, names and structure, looks good to me.
I would just change, in the SecondaryTableBinding, the attribute name
"predicate" to "foreignKey"
On 14 April 2017 at 18:24, Steve Ebersole <st...@hibernate.org> wrote:
> Before I get deeper into this persister work I wanted to discuss some of
> the primary design concepts and start a discussion about naming the
> interfaces/classes related to them.
>
> I am thinking it would be best to model the tables associated with a
> persister using a similar structure we use for
> TableSpace/TableGroup/TableGroupJoin but in the non-specific-reference
> case. For example, the Person entity might be mapped to 2 tables: the
> primary PERSON table, and a PERSON_SUPP secondary table. Inside the
> persister we'd map the binding to those tables including the join criteria
> between them. This is distinctly different from the structure of
> references to those tables as part of a specific query. So inside
> persister we'd map a structure like:
>
> EntityPersister {
> ...
> rootTable = Table( PERSON )
> secondaryTables = {
> SecondaryTableBinding {
> joinType = INNER
> targetTable = Table( PERSON_SUPP )
> predicate = {
> EQ {
> lhs = {
> ColumnBinding( Column( Table( PERSON ), "id" )
> }
> rhs = {
> ColumnBinding( Column( Table( PERSON_SUPP ), "p_id"
> )
> }
> }
> }
> }
> }
>
> We could simplify this if we follow the same assumption we do today that
> the secondary tables always use the root table as the lhs. Additionally we
> might consider simplifying the join predicate to use the ForeignKey which
> already defines this join predicate info:
>
> EntityPersister {
> ...
> rootTable = Table( PERSON )
> secondaryTables = {
> SecondaryTableBinding {
> joinType = INNER
> targetTable = Table( PERSON_SUPP )
> predicate = ForeignKey {
> uid = 123456789ABC
> ...
> }
> }
> }
> }
>
>
> Compare this to the structure for a particular query[1], which is
> different:
>
> TableGroup
> root = TableReference {
> table = ( Table( PERSON ) )
> identifiactionVariable = p0
> tableJoins = {
> TableReferenceJoin {
> ...
> }
> }
> }
> }
>
> Notice specifically the addition of the identifactionVariable (alias).
> Because we might have multiple references to that same table which need to
> be unique in the given query, e.g. a fetched or joined self-referential
> association (person -> manager).
>
> First, what do you think of these proposed structures? And secondly what
> are y'alls opinions wrt the names?
>
> FWIW there are 2 main reasons I propose modeling things the way I suggest
> above in terms of the structure on persisters:
>
> 1. I think it makes it easier for consumers of persisters to understand
> the bindings
> 2. I *think* (tbd) that it makes it easier to "clone" into the query
> TableGroup structure.
>
> Anyway, would love feedback on this.
>
> [1] Note that the class called `TableReference` here is called
> `TableBinding` in the currently pushed code, but I'd prefer to change that
> and instead have "binding" term reference the binding of the table in the
> persister model. I am open to different naming here though.
> _______________________________________________
> 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
