| I've attached 3 more testcases which demonstrates why this issue results in incorrect queries. All tests use the following set of 4 entities:
SubType1(basevalue = 100, subvalue1 = 100)
SubType1(basevalue = 200, subvalue1 = 200)
SubType2(basevalue = 100, subvalue2 = 100)
SubType2(basevalue = 200, subvalue2 = 200)
The first case involves a treat inside a not:
select e from BaseType as e where not(treat(e as SubType1).subvalue1 = 100)
This is incorrectly translated into the following SQL:
select * from BaseType basetype0_ where
basetype0_.DTYPE='SubType1'
and basetype0_.subvalue1<>100
The second example uses a restriction on a property in the base class, combined with a restriction on a sub-property:
select e from BaseType as e where e.basevalue = 100 or treat(e as SubType1).subvalue1 = 200
The lifting of the DTYPE, causes only entities of type SubType1 to be returned:
select * from BaseType basetype0_ where
basetype0_.DTYPE='SubType1'
and (
basetype0_.basevalue=100
or basetype0_.subvalue1=200
)
The last testcase demonstrates a case where a property from the base type is selected on a treated path. The spec dictates that predicate with the treat should evaluate to false for all rows not of type SubType1, but when combined with an or on another type, this restriction is lost, causing all rows to be returned:
select e from BaseType as e where treat(e as SubType1).basevalue = 100 or treat(e as SubType2).subvalue2 = 200
SQL:
select * from BaseType basetype0_ where
basetype0_.DTYPE in ('SubType2', 'SubType1')
and (
basetype0_.basevalue=100
or basetype0_.subvalue2=200
)
|