Serialized predicate causes issues with ConstImpl cache

[jotomo]

Im' using QueryDSL 2.9.0 with Spring Data JPA 1.3.4.

I have a client which contstructs a predicate, like this: 'QAdress.adress.name.eq("test")'. This is then serialized, send over the wire to the server and deserialized. The serialization process itself is fine and does no harm to the predicate. However, executing this query on the server (using Spring Data JPA, although this is definately not a relevant factor), I get an exception "Undeclared path 'adress'. Add this path as a source to the query to be able to reference it.". I checked the source of the exception, ValidatingVisitor.visit(Path<?> expr, Void context). This method checks if the root path of the predicate (adress) is known, more precisely, if the field 'known' contains the root of the expression (adress again). Where 'known' is a hashmap and hence uses hashcodes to determine if it contains an object. The hashcode is generated using HashCodeVisitor, which uses the metadata (PathType, parent and expression) to generate a hashcode. The 'known' field does contain an entry 'adress'. I compared this with the predicate; PathType is VARIABLE, parent is null and expression is a ConstantImpl with the value 'adress'. However, the ConstantImpl in 'known' is a different object than the one in the predicate, which makes me believe they have different hashcodes, and the cause why I get the exception. I haven't debugged further, but I'd suspect that caching may have to do with this, since the predicate was instanciated on the client, hence in a different JVM than on the server side (predicate execution and serialization works without problems in a unit test on the same JVM). As QueryDSL supports serialization AFAIK, this scenario should be supported too, right?

[timowest]

The latest version of Querydsl doesn't have a String constant cache anymore. Is upgrade to a newer Querydsl version an option for you?

I also verified that local serialization/deserialization works properly with a test.

[jotomo]

I upgraded to Spring Data JPA 1.4.0.RC1 (first version to support QueryDSL 3.2.2). The bogus source message is gone :-) Thanks Timo!

[jotomo]

Okay, so maybe that's not the whole story ...
The predicate can be executed now with the source as requested, however, I now get an error, but only for the very first request. All subsequent requests are fine:

15:57:08.228 [tomcat-http--3] INFO  d.n.i.e.b.s.domain.EntitiesService - Got search predicate: containsIc(standort.adresse.name1,Wellpappenwerk)
15:57:08.322 [tomcat-http--3] ERROR d.n.i.e.b.w.c.AbstractController - Unhandled exception
[Spring exception removed]
Caused by: java.lang.IllegalArgumentException: Got no pattern for null
    at com.mysema.query.support.SerializerBase.visitOperation(SerializerBase.java:287) ~[querydsl-core-3.2.2.jar:na]
    at com.mysema.query.jpa.JPQLSerializer.visitOperation(JPQLSerializer.java:395) ~[querydsl-jpa-3.2.2.jar:na]
    at com.mysema.query.support.SerializerBase.visit(SerializerBase.java:246) ~[querydsl-core-3.2.2.jar:na]
    at com.mysema.query.support.SerializerBase.visit(SerializerBase.java:42) ~[querydsl-core-3.2.2.jar:na]
    at com.mysema.query.types.OperationImpl.accept(OperationImpl.java:91) ~[querydsl-core-3.2.2.jar:na]
    at com.mysema.query.support.SerializerBase.handle(SerializerBase.java:102) ~[querydsl-core-3.2.2.jar:na]
    at com.mysema.query.jpa.JPQLSerializer.serialize(JPQLSerializer.java:208) ~[querydsl-jpa-3.2.2.jar:na]
    at com.mysema.query.jpa.JPAQueryBase.buildQueryString(JPAQueryBase.java:64) ~[querydsl-jpa-3.2.2.jar:na]
    at com.mysema.query.jpa.JPAQueryBase.toCountRowsString(JPAQueryBase.java:236) ~[querydsl-jpa-3.2.2.jar:na]
    at com.mysema.query.jpa.impl.AbstractJPAQuery.count(AbstractJPAQuery.java:80) ~[querydsl-jpa-3.2.2.jar:na]
    at org.springframework.data.jpa.repository.support.QueryDslJpaRepository.findAll(QueryDslJpaRepository.java:114) ~[spring-data-jpa-1.4.0.RC1.jar:na]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_21]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_21]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_21]
    at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_21]
    at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.executeMethodOn(RepositoryFactorySupport.java:333) ~[spring-data-commons-1.6.0.RC1.jar:na]
    at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:318) ~[spring-data-commons-1.6.0.RC1.jar:na]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) ~[spring-aop-3.2.4.RELEASE.jar:3.2.4.RELEASE]
    at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:96) ~[spring-tx-3.2.4.RELEASE.jar:3.2.4.RELEASE]
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:260) ~[spring-tx-3.2.4.RELEASE.jar:3.2.4.RELEASE]
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94) ~[spring-tx-3.2.4.RELEASE.jar:3.2.4.RELEASE]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) ~[spring-aop-3.2.4.RELEASE.jar:3.2.4.RELEASE]
    at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155) ~[spring-tx-3.2.4.RELEASE.jar:3.2.4.RELEASE]
    ... 52 common frames omitted

The predicate in this example is a bit different, but that's not the issue, I've tested it with the original predicate too, the deciding factor is that it's the first time a predicate is executed server-side.
I already spend days hunting down the original issue, so any hint would be greatly appreciated. If you need more info, let me know what.

[timowest]

This looks like a bug in the deserialization of OperationImpl. I will see how it could be fixed.

[timowest]

Could you test with the latest SNAPSHOT from here https://oss.sonatype.org/content/repositories/snapshots/

It looks like some optimization I did for Expression creation and comparison didn't work in the case when serialized expressions are used.

[jotomo]

Thanks, I'll give it a try on Monday.

[jotomo]

Your commit fixed the bug. I wrote a bunch of tests to exercise a bit more of QueryDSL beyond the original select and it's all working smoothly. Thanks a lot Timo! :-)

[timowest]

Good. I'll close it when it's released.

[timowest]

Released in 3.2.3