I think it is ok to disallow implicit downcasting in cases where the
downcast is non-deterministic. From you example domain, I think it is ok
to disallow the implicit downcast in : `from BaseEntity e where
e.relation.id = ...' with either a specific error ("cannot implicitly
downcast BaseEntity to (EntityA, EntityB) due to named attributes being
unrelated") or a general "un-resolved attribute" error. On option to
address that would be to change your registering a null, to instead
recognizing that the passed property fits this description in its
PropertyMapping impls and throw such an exception.
And I think as long as you remove it from that entity's/component's various
attribute-info arrays it should handle the SQL generation too.
If you like that approach better...
On Mon, Mar 12, 2018 at 12:02 PM andrea boriero <and...@hibernate.org>
wrote:
> Hi Christian,
> I have looked at your PR and at the moment I cannot find another easy clean
> solution for this issue not requiring as you said quite a lot of work.
>
>
>
> On 9 March 2018 at 20:20, Christian Beikov <christian.bei...@gmail.com>
> wrote:
>
> > Hey,
> >
> > so the problems related to the type variable handling I did aren't fully
> > solved. There is one other case that was reported today:
> > https://hibernate.atlassian.net/browse/HHH-12375
> >
> > I'm not sure how to handle this. Let me explain you the model and the
> > problem.
> >
> > @Entity class BaseEntity { @Id Integer id; }
> > @Entity class EntityA extends BaseEntity { @ManyToOne EntityC relation; }
> > @Entity class EntityB extends BaseEntity { @ManyToOne EntityD relation; }
> > @Entity class EntityC {...}
> > @Entity class EntityD {...}
> >
> > The essence is, that EntityA and EntityB define properties with the same
> > names but have unrelated types. It's actually the same problem for
> > collections.
> >
> > Since EntityA and EntityB extend BaseEntity and because BaseEntity is an
> > @Entity, the Hibernate code tries to add "EntityA.relation" and
> > "EntityB.relation" to the PropertyMapping of BaseEntity. Before my fix,
> > the property which is added first won and subsequent adds are ignored.
> > This is presumably done to support implicit downcasting. My fix was
> > about making use of a common super type if possible and disallowing
> > ambiguous access.
> >
> > The problem the user now reported is, when using FetchType.EAGER there
> > is an exception which states that property "relation" could not be found
> > on type "BaseEntity". This is because I register "null" as type to
> > signal that it's not really possible to use that property with that
> > persister(BaseEntity in this case). During booting, the load plan for
> > BaseEntity is built, for which the SQL is pre-generated. At this point,
> > the exception happens, because "null" is registered as type for the
> > property "relation". This will cause the property to be considered as
> > non-existant wrt getPropertyType. The code before my fix was essentially
> > broken, because it doesn't handle eager fetching properly due to the
> > "first property wins" strategy. A property might only be loaded through
> > a secondary query due to lazy loading rather than by the defined fetch
> > style. An implicit downcasted join using the property might lead to
> > non-deterministic results.
> >
> > One of the reasons for doing the fix, was to prevent the possibility of
> > being hit by the non-determinism. I had a mapping that was using the
> > type variable approach and I had to find out the non-determinism the
> > hard way. I'd like to prevent access to such conflicting attributes from
> > the top level type through implicit downcasting, so IMO the only real
> > solution is to exclude the conflicting attributes in the load plan.
> >
> > The "best" solution would be to introduce a synthetic type that
> > represents the union of the unrelated property types, but to me this
> > seems to be quite a lot of work.
> >
> > I have implemented the proposed solution here:
> > https://github.com/hibernate/hibernate-orm/pull/2190
> >
> > We need to release this fix soon as the current state is broken for the
> > EAGER configuration. What do you think about the solution or the matter
> > in general?
> >
> > --
> >
> > Mit freundlichen Grüßen,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> > _______________________________________________
> > 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
