11:24 a.m.
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.
3:13 a.m.
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 <steve(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:59 a.m.
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? :)
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 14.04.2017 um 18:24 schrieb Steve Ebersole:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:35 a.m.
On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <christian.beikov(a)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".
9:01 a.m.
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> wrote:
On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <
christian.beikov(a)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".
9:43 a.m.
I lean to your 3th option
On 3 May 2017 at 15:01, Steve Ebersole <steve(a)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(a)hibernate.org>
wrote:
> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <
> christian.beikov(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:54 a.m.
Option 1 sounds good.
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(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".
4:55 a.m.
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(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".
7:42 a.m.
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 <steve(a)hibernate.org> wrote:
> On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov <
> christian.beikov(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2788
days inactive
2808
days old
8 comments
4 participants
participants (4)
-
andrea boriero -
Chris Cranford -
Christian Beikov -
Steve Ebersole