Spring Data GemFire 1.7
The purpose of this article is to describe the upcoming new feature in SDG 1.7
A new feature of Spring Data GemFire to help simplify the development of GemFire/Geode applications using Spring is support for GemFire OQL Query Language extensions (e.g. IMPORT, TRACE) via custom Java Annotations (i.e. @Import, @Trace, etc).
It is undesirable when using a data access abstraction, like Spring Data Commons' Repositories or even Hibernate, to have to resort to using "raw" Query Language syntax to specify your queries. Sometimes this is necessary to exploit data store specific optimizations or syntax features.
While Hibernate can maintain relational model, structured query language agnostics (i.e. HQL) to compensate for different SQL, relational data store dialects, SDG maintains portable querying across diverse data stores, including non-relational, or [non|not-only]-SQL based data stores. I.e. you can (re-)use your same application domain-specific Repository interfaces against SQL and [non|not-only]-SQL stores alike as well as between different [non|not-only]-SQL stores (e.g. GemFire and Redis, or Hazelcast). In addition, some Spring Data Repository implementations (such as SD JPA) take it a step further and even have support for QueryDSL.
To move Spring Data GemFire forward and in the same general direction, we have added GemFire Query Language (OQL) extensions support via Annotations, currently including: @Hint, @Import, @Limit and @Trace.
This allows you to customize a Repository query method like the following:
@Trace @Limit(10) @Hint("LastNameIdx") List<Customer> findDistinctCustomerByLastName
This results in the following OQL Query:
<TRACE> <HINT 'LastNameIdx'> SELECT DISTINCT * FROM /Customers c WHERE c.lastName LIKE $1 ORDER BY c.lastName ASC LIMIT 10
Here, you can see OQL Query level debugging is enabled along with applying a OQL Index Hint and limiting the query result set to the first 10 results based on the ordering defined.
To achieve the same result, previously an application developer would need to specify the "raw" Query using the @Query annotation like the following:
@Query("<TRACE> <HINT 'LastNameIdx'> SELECT DISTINCT * FROM /Customers c WHERE c.lastName LIKE $1 ORDER BY c.lastName ASC LIMIT 10") List<Customer> findBy(String lastName)
In this example, the query method signature is rendered useless by the presence of the raw query (using @Query) and thus will not be used by the Repository infrastructure. This was necessary before in order to achieve query level debugging, query hints and limits on the result set. Though, as result, you give up much of the expressed power and portability that is intrinsic in the Repository infrastructure out-of-the-box at your own expense and unnecessarily tightly coupled your application to GemFire/Geode.
For more details on this upcoming feature in SDG 1.7 look out for the release on the Spring project.