I am experiencing some buggy behaviour regarding the TREAT operator on MapJoins. In the following I will only sketch the scenario, for the full detail see the attached maven project.
I have an entity
{code:java}
class DBObject {
private Map<DBKey, DBValue> properties;
}
{code}
that holds a mapping from keys (entities) to values (also entities). DBValue is an abstract super class for several subclasses that store a specific value, e.g. DBValueWithString or DBValueWithReference (which references other DBObjects).
I now want to query for objects, that own specific properties with certain values. Therefore I use the following CriteriaQuery:
{code:java}
final CriteriaBuilder builder = em.getCriteriaBuilder();
final CriteriaQuery<DBObject> query = builder.createQuery(DBObject.class);
final Root<DBObject> from = query.from(DBObject.class);
final MapJoin<DBObject, DBKey, DBValue> valueJoin = from.join(DBObject_.properties);
final MapJoin<DBObject, DBKey, DBValueWithString> stringJoin = builder.treat(valueJoin, DBValueWithString.class);
final Predicate predicate1 = builder.and(
builder.equal(stringJoin.get(DBValueWithString_.key), key1),
builder.equal(stringJoin.get(DBValueWithString_.value), "test")
);
{code}
This query generates to reasonable JPQL:
{noformat}
select
generatedAlias0
from
DBObject as generatedAlias0
inner join
generatedAlias0.properties as generatedAlias1
where
(
treat(generatedAlias1 as de.mtf.DBValueWithString).key=:param0
)
and (
treat(generatedAlias1 as de.mtf.DBValueWithString).value=:param1
)
{noformat}
The corresponding SQL seems a little off, however it works:
{noformat}
select
dbobject0_.id as id1_1_
from
DBObject dbobject0_
inner join
DBValue properties1_
on dbobject0_.id=properties1_.object_id
inner join
DBValueWithString properties1_1_
on properties1_.id=properties1_1_.id
left outer join
DBValueWithReference properties1_2_
on properties1_.id=properties1_2_.id
where
properties1_.key_id=?
and properties1_1_.value=?
{noformat}
Note the unnecessary join with DBValueWithReference. According to the doc, the TREAT operator should also filter out the non matching subtypes, therefore entities of type DBValueWithReference can be completely ignored at this point.
The problem now arises, when querying for DBValueWithReferences. The JPQL query seems fine once again:
{noformat}
select
generatedAlias0
from
DBObject as generatedAlias0
inner join
generatedAlias0.properties as generatedAlias1
where
(
treat(generatedAlias1 as de.mtf.DBValueWithReference).key=:param0
)
and (
treat(generatedAlias1 as de.mtf.DBValueWithReference).value=:param1
)
{noformat}
However the translation process to SQL fails with the following error message:
{noformat}
java.lang.IllegalArgumentException: Parameter value [de.mtf.DBObject@7bf9b098] did not match expected type [java.lang.String (n/a)]
at org.hibernate.jpa.spi.BaseQueryImpl.validateBinding(BaseQueryImpl.java:897)
at org.hibernate.jpa.internal.QueryImpl.access$000(QueryImpl.java:61)
at org.hibernate.jpa.internal.QueryImpl$ParameterRegistrationImpl.bindValue(QueryImpl.java:235)
at org.hibernate.jpa.spi.BaseQueryImpl.setParameter(BaseQueryImpl.java:638)
at org.hibernate.jpa.spi.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:163)
at org.hibernate.jpa.spi.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:32)
at org.hibernate.jpa.criteria.compile.CriteriaCompiler$1$1.bind(CriteriaCompiler.java:109)
at org.hibernate.jpa.criteria.CriteriaQueryImpl$1.buildCompiledQuery(CriteriaQueryImpl.java:369)
at org.hibernate.jpa.criteria.compile.CriteriaCompiler.compile(CriteriaCompiler.java:130)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:699)
at de.mtf.TreatTest.testTreat(TreatTest.java:98)
{noformat}
The problem seems to correlate with the unnecessary join, as the type seems to be inferred solely based on the first join (with DBValueWithString), which is unnecessarily part of the second query.
It seems, DBValue is joined with every sub class that is encountered in the persistence.xml. If you uncomment the @Entity annotation for DBValueWithBoolean, it will occur in the list of join statements.
Moreover, the order of the joins seems to depend on the order of which the classes are listed in the persistence.xml. If you swap the entries for DBValueWithString and DBValueWithReference, the second query executes just fine, whereas the first query now yields:
{noformat}
java.lang.IllegalArgumentException: Parameter value [test] did not match expected type [de.mtf.DBObject (n/a)]
at org.hibernate.jpa.spi.BaseQueryImpl.validateBinding(BaseQueryImpl.java:897)
at org.hibernate.jpa.internal.QueryImpl.access$000(QueryImpl.java:61)
at org.hibernate.jpa.internal.QueryImpl$ParameterRegistrationImpl.bindValue(QueryImpl.java:235)
at org.hibernate.jpa.spi.BaseQueryImpl.setParameter(BaseQueryImpl.java:638)
at org.hibernate.jpa.spi.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:163)
at org.hibernate.jpa.spi.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:32)
at org.hibernate.jpa.criteria.compile.CriteriaCompiler$1$1.bind(CriteriaCompiler.java:109)
at org.hibernate.jpa.criteria.CriteriaQueryImpl$1.buildCompiledQuery(CriteriaQueryImpl.java:369)
at org.hibernate.jpa.criteria.compile.CriteriaCompiler.compile(CriteriaCompiler.java:130)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:699)
at de.mtf.TreatTest.testTreat(TreatTest.java:96)
{noformat}
So is this just a misinterpretation of what the TREAT operator is supposed to do, or is it actually a bug in the SQL generation?
|
|