0

Do you know if it is possible to do the following using springDataGemfire:

@Query("$1")
List<String> getQuery(String Query);

we are trying to build a dynamic query and then run it on GemFire

we are getting the below error :

org.springframework.dao.InvalidDataAccessApiUsageException: Result object returned from GemfireCallback isn't a SelectResult:

Best regards, Farid

1 Answers1

2

Farid-

The SD[G] Repository infrastructure and extension for Pivotal GemFire, and in particular, the explicit OQL query using the @Query annotation, was never meant to be used in this way.

Essentially, you are attempting to use the SD Repository infrastructure to run "ad hoc" GemFire OQL queries, therefore, why not use the GemfireTemplate directly, or even GemFire's QueryService API for this purpose?

What you are attempting to do is akin to using Hibernate for complex queries beyond mapping and ordinary queries (which is not really the purpose of Hibernate) when JDBC directly (or Spring's JdbcTemplate) is more appropriate for advance querying capabilities.

It is still possible to use a hybrid approach though, where the "provided" SD Repository infrastructure handles the majority of your application's data access patterns (e.g. CRUD, simple queries, etc) and you combine that with a "custom" Repository implementation.

I have an example of such a "custom" Repository implementation for GemFire in my Contacts Application RI for SDG, here. The CustomerRepository extends CustomerRepositoryExtension, which is implemented in the CustomerRepositoryImpl class. SD's Repository infrastructure picks up this "custom" implementation when creating the Repository proxy for the CustomerRepository interface. In this case, I am having the "custom Repository data access/query method call a GemFire Function (as can be seen here).

In your case, it is a simple matter to run the passed in, dynamic OQL query using the SDG GemfireTemplate or GemFire's QueryService API directly.

Hope this helps! -John

John Blum
  • 7,381
  • 1
  • 20
  • 30
  • Also note, in your particular example the OQL statement passed by the SD Repository infrastructure is the @Query annotation value (i.e. "$1") which is not a valid GemFire OQL (query) statement as handled by http://gemfire-90-javadocs.docs.pivotal.io/org/apache/geode/cache/query/QueryService.html#newQuery-java.lang.String-. Essentially the query method (i.e. "getQuery(..)") parameter (i.e. "Query") value, the actual OQL (query) statement is the argument to http://gemfire-90-javadocs.docs.pivotal.io/org/apache/geode/cache/query/Query.html#execute-java.lang.Object:A-, which simply does not work. – John Blum Mar 17 '17 at 02:33
  • 1 final comment... I added a test for you UC in my test project, here (https://github.com/jxblum/spring-gemfire-tests/blob/master/src/test/java/org/spring/data/gemfire/cache/RepositoryWithDynamicQueriesIntegrationTests.java). I wrote 3 test cases... – John Blum Mar 17 '17 at 03:06
  • The first test case, `springDataGemFireDynamicQueryTest` (https://github.com/jxblum/spring-gemfire-tests/blob/master/src/test/java/org/spring/data/gemfire/cache/RepositoryWithDynamicQueriesIntegrationTests.java#L127-L133) demonstrates your UC. This test fails as expected based on "answer" above. – John Blum Mar 17 '17 at 03:08
  • The second test case, `gemfireQueryTest` (https://github.com/jxblum/spring-gemfire-tests/blob/master/src/test/java/org/spring/data/gemfire/cache/RepositoryWithDynamicQueriesIntegrationTests.java#L117-L125) demonstrates what the SD[G] Repository abstraction/infrastructure and extension for Pivotal GemFire translates the "dynamic OQL query" method (e.g. "`getQuery(:String)`" to in terms of GemFire API calls. This test also fails! – John Blum Mar 17 '17 at 03:11
  • Finally, the third test case, `springDataGemFireCustomDynamicQueryTest` (https://github.com/jxblum/spring-gemfire-tests/blob/master/src/test/java/org/spring/data/gemfire/cache/RepositoryWithDynamicQueriesIntegrationTests.java#L135-L142) demonstrates how you can properly handle "dynamic OQL queries" in your application Repositories. This test **passes** as expected! – John Blum Mar 17 '17 at 03:12