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 o
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 defini
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 pr
I lean to your 3th option
On 3 May 2017 at 15:01, 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
> metamo
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.
An
On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov
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
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
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 wrote:
> Before I get deeper into this persister work I wanted to discuss some of
> the primary desig
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
Tabl
