@Udo is correct, here!
Storing or exposing some timestamp (long
or `Long' value) on your application domain object(s), that are stored and managed in VMware GemFire, is actually preferable in this case.
It could even look something like this...
package example.app.customers.model;
import java.time.Instant
...
@Region("Customers")
class Customer {
private Long id;
private Instant joined;
private final String name;
public long getJoinedTimestamp() {
Instant localJoined = this.joined;
return localJoined != null ? localJoined.toEpochMilli() : 0L;
}
// other getters, setters and accessors omitted
}
However, I would NOT use java.util.Calendar
, but rather use the (@since
) Java 8 date/time types in the java.time
package (Javadoc), like java.time.Instant
(Javadoc).
Then, it would also be a simple matter to write a derived query using the Spring Data (SD) [GemFire] Repository abstraction, too!
There is no need to use GemFire's OQL-based query API (:P) in this case!
So, you could have SD GemFire Repository declaration like the following:
package example.app.customers.repo;
interface CustomerRepository extends CrudRepository<Customer, Long> {
List<Customer> findByJoinedTimestampGreaterThanEqualAndJoinedTimestampLessThan(Long begin, Long end);
NOTE: The time range could be inclusive, too, such as findByJoinedTimestampGreaterThanEqualAndJoinedTimestampLessThanEqual(..)
as well.
NOTE: In my example above, the joined timestamp is inclusive on the lower bound and exclusive on the upper bound.
You can find out more about Spring Data GemFire's (SDG) extension of Spring Data's (SD) Repository infrastructure and querying capabilities here, in the SDG doc, and specifically on SDG derived (OQL) queries in doc as well.
For more general information on the Spring Data Repository infrastructure abstraction, see the Spring Data Commons' documentation, and specifically about query methods.
Good luck!