java.lang.IllegalArgumentException: Parameter value [test] did not match expected type [de.mtf.DBObject (n/a)]

Hibernate JIRA | M F | 1 year ago
tip
Your exception is missing from the Samebug knowledge base.
Here are the best solutions we found on the Internet.
Click on the to mark the helpful solution and get rewards for you help.
  1. 0

    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? ***EDIT*** To further elaborate on this issue, I tried to realize the same scenario using the EclipseLink JPA provider. Thereby I realized, the code given in the example may be a little unclean. For example, I used the same Join-object in several calls to the treat function. Apparently, this function may alter the Join-object, which may cause the query to fail. I added a new test project, which hopefully gets rid of all these flaws. Ultimately, the new test-case allows a direct comparison of Hibernate and EclipseLink (via maven profiles) which shows, that the code executes as expected using EclipseLink but fails when using Hibernate. The main issue seems to be the same as mentioned above: When performing the TREAT operation, Hibernate wrongly joins on every subtype of the superclass.

    Hibernate JIRA | 1 year ago | M F
    java.lang.IllegalArgumentException: Parameter value [test] did not match expected type [de.mtf.DBObject (n/a)]
  2. 0

    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? ***EDIT*** To further elaborate on this issue, I tried to realize the same scenario using the EclipseLink JPA provider. Thereby I realized, the code given in the example may be a little unclean. For example, I used the same Join-object in several calls to the treat function. Apparently, this function may alter the Join-object, which may cause the query to fail. I added a new test project, which hopefully gets rid of all these flaws. Ultimately, the new test-case allows a direct comparison of Hibernate and EclipseLink (via maven profiles) which shows, that the code executes as expected using EclipseLink but fails when using Hibernate. The main issue seems to be the same as mentioned above: When performing the TREAT operation, Hibernate wrongly joins on every subtype of the superclass.

    Hibernate JIRA | 1 year ago | M F
    java.lang.IllegalArgumentException: Parameter value [test] did not match expected type [de.mtf.DBObject (n/a)]
  3. 0

    optional parameters jpa 2.1

    Stack Overflow | 3 months ago | Ammar Samater
    java.lang.IllegalArgumentException: Parameter value [0] did not match expected type [entity.Lang (n/a)]
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Hibernate recognizes a number of special "collection properties" when querying collections. This includes things like the size of the collection, the maxindex, the minindex, etc. The historical way to reference these was to use a "pseudo property" in the query. E.g., in HQL you'd have said {{select ... from Room r join r.walls w where w.size > 1}}. However that causes an ambiguity and "hides" a possible "real" attribute {{Wall#size}}. The preferred way to refer to these is using a "collection function" any way ({{... size(w) > 1}}) because there is no ambiguity. In cases where the element actually defines an attribute that is also one of these "pseudo collection properties", prefer the interpretation using the Entity attribute. ---- h4. Original description +In short+: * Two JPA-entites A and B are mapped via @OneToMany. * B contains an enum field named 'size'. * When querying (JPA-Criteria-API) on 'A join B' using where on the field 'size', java.lang.IllegalArgumentException (Parameter value [...] did not match expected type [java.lang.Integer]) is thrown. * Renaming the field to anything other than 'size' fixes the issue. +More detailed:+ {code:java} @Entity public class A { @OneToMany(cascade={CascadeType.ALL}) private List<B> bs; ... } {code} {code:java} @Entity public class B { @Enumerated(EnumType.STRING) private AnyEnumType size; ... } {code} {code:java} //Method fails with exception public List<A> findBySize(AnyEnumType size) { CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder(); CriteriaQuery<A> query = criteriaBuilder.createQuery(A.class); Root<A> root = query.from(A.class); Path<AnyEnumType> path = root.<A,B>join("bs").<AnyEnumType>get("size"); query.where(criteriaBuilder.equal(path, size)); //Throws here return entityManager.createQuery(query).getResultList(); } {code} The following exception is thrown: {code:java} java.lang.IllegalArgumentException: Parameter value [LARGE] did not match expected type [java.lang.Integer (n/a)] at org.hibernate.jpa.spi.BaseQueryImpl.validateBinding(BaseQueryImpl.java:858) at org.hibernate.jpa.internal.QueryImpl.access$000(QueryImpl.java:62) at org.hibernate.jpa.internal.QueryImpl$ParameterRegistrationImpl.bindValue(QueryImpl.java:235) at org.hibernate.jpa.spi.BaseQueryImpl.setParameter(BaseQueryImpl.java:603) 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) ... {code} Attached you'll find one testcase to reproduce the issue.

    Hibernate JIRA | 2 years ago | Thomas Rauner
    java.lang.IllegalArgumentException: Parameter value [LARGE] did not match expected type [java.lang.Integer (n/a)]
  6. 0

    Path expected for join!

    GitHub | 2 years ago | shazin
    java.lang.IllegalArgumentException: org.hibernate.hql.internal.ast.QuerySyntaxException: Path expected for join! [select testEntity2 from my.mimos.jpa.entity.TestEntity2 testEntity2 inner join fetch TestEntity1 testEntity1 where testEntity2.parent.id = testEntity1.id]

  1. MoYapro 1 times, last 6 months ago
3 unregistered visitors
Not finding the right solution?
Take a tour to get the most out of Samebug.

Tired of useless tips?

Automated exception search integrated into your IDE

Root Cause Analysis

  1. java.lang.IllegalArgumentException

    Parameter value [test] did not match expected type [de.mtf.DBObject (n/a)]

    at org.hibernate.jpa.spi.BaseQueryImpl.validateBinding()
  2. org.hibernate.jpa
    AbstractEntityManagerImpl.createQuery
    1. org.hibernate.jpa.spi.BaseQueryImpl.validateBinding(BaseQueryImpl.java:897)
    2. org.hibernate.jpa.internal.QueryImpl.access$000(QueryImpl.java:61)
    3. org.hibernate.jpa.internal.QueryImpl$ParameterRegistrationImpl.bindValue(QueryImpl.java:235)
    4. org.hibernate.jpa.spi.BaseQueryImpl.setParameter(BaseQueryImpl.java:638)
    5. org.hibernate.jpa.spi.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:163)
    6. org.hibernate.jpa.spi.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:32)
    7. org.hibernate.jpa.criteria.compile.CriteriaCompiler$1$1.bind(CriteriaCompiler.java:109)
    8. org.hibernate.jpa.criteria.CriteriaQueryImpl$1.buildCompiledQuery(CriteriaQueryImpl.java:369)
    9. org.hibernate.jpa.criteria.compile.CriteriaCompiler.compile(CriteriaCompiler.java:130)
    10. org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:699)
    10 frames
  3. de.mtf
    TreatTest.testTreat
    1. de.mtf.TreatTest.testTreat(TreatTest.java:96)
    1 frame