Проблема не в Spring Data GemFire.
Также было бы полезно, если бы вы включили версии как Spring Data GemFire, так и Pivotal GemFire, которые вы используете (например, Spring Data GemFire 1.9.10.RELEASE
, который вытягивает Pivotal GemFire 8.2.8
или, возможно, вы используете Spring Data GemFire 2.0.4.RELEASE
, который извлечет Основной GemFire 9.1.1
; см. страница совместимости версий для более подробной информации) .
Хотя эта проблема очевидна сразу, вы также можете помнить о том, чтобы в следующий раз включить любые трассировки стека или выходные данные журнала.
Итак, проблемы, которые у вас возникают, напрямую связаны с этим...
1) Относительно timestamp
....
timestamp
— это зарезервированное слово и запрос OQL поддерживаемый литерал. Вы не можете использовать «timestamp
» в качестве поля или свойства объектов вашего домена (например, Trade
).
2) Относительно ORDER BY
...
Pivotal GemFire не поддерживает запросы без DISTINCT, ORDER BY (4-я пуля).
Ни одна из этих проблем не связана с Spring Data GemFire. Это основные ограничения и ограничения GemFire.
Если вы хотите понять, как для создания правильных и правильных операторов OQL (запросов).
И последний совет: ваш запрос не такой сложный и его можно было бы легко правильно выразить, используя абстракцию метода запроса репозитория, вместо того, чтобы прибегать к использованию @Query
, что в данном случае не требуется...
interface TradeRepository extends CrudRepository<Trade, Long> {
@Limit(15)
List<Trade> findDistinctTradeByStockSymbolOrderByTradeTimestampDesc(String stockSymbol);
}
Вот такая же сложная реализация репозитория (например, ContactRepository
), которая также включает методы запросов, генерирующие правильный GemFire OQL с использованием «соглашения», например, для вложенных типов.
Посмотрите на некоторые другие "методы запросов" в этом определении интерфейса Repository (для Contact
) для других примеров того, что возможно.
Соответствующий интеграционный тест для ContactRepository
можно найти здесь.
-j
person
John Blum
schedule
28.02.2018