When mixing table-per-subclass with table-per-class-hierarchy, problem mapping inverse one-to-many relationship to derived entity
Description
The attached test case can be used to reproduce. It includes two different inheritance mappings, one using standard TablePerSubclass without a discriminator, and one that uses a discriminator. The non-discriminator version works fine. The version with a discriminator generates an incorrect mapping (the AggregateRootId is created on both BaseEntity and DerivedEntity) and when lazy-loading the OneToMany collection, the join is against the AggregateRootId column on BaseEntity, which is null.
It seems to have something to do with the way the joined-subclass is mapped using a SingleTableSubclass when mixing inheritance strategies.
This is quite an important issue for us. I am willing to investigate further to try to come up with a proposed patch, however first wanted to confirm that my analysis was correct.
The attached test case can be used to reproduce. It includes two different inheritance mappings, one using standard TablePerSubclass without a discriminator, and one that uses a discriminator. The non-discriminator version works fine. The version with a discriminator generates an incorrect mapping (the AggregateRootId is created on both BaseEntity and DerivedEntity) and when lazy-loading the OneToMany collection, the join is against the AggregateRootId column on BaseEntity, which is null.
It seems to have something to do with the way the joined-subclass is mapped using a SingleTableSubclass when mixing inheritance strategies.
This is quite an important issue for us. I am willing to investigate further to try to come up with a proposed patch, however first wanted to confirm that my analysis was correct.