[hibernate-dev] Joins over type variable defined assocations NPE problems

[andrea boriero]

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.beikov at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev