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

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 <http://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 <andrea(a)hibernate.org <mailto:andrea@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.beikov(a)gmail.com <mailto:christian.beikov@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev