Spring Data GemFire ​​и «неожиданный токен» в ручном запросе OQL

Я запускаю запрос с помощью Spring Data GemFire и получаю ``Синтаксическая ошибка в запросе: неожиданный токен: метка времени.

Я не могу понять проблему.

@Query("SELECT * FROM /Trade T WHERE T.stock.symbol =$1 ORDER BY T.timestamp desc LIMIT 15")
  public List<Trade> findAllTradeForStock(String stock);

Торговый класс:

public class Trade implements Serializable {

  private static final long serialVersionUID = 3209342518270638001L;

  @Id private int tradeIdentifier;
  private Stock stock;
  private LocalDateTime timestamp;

}


person Chandresh Mishra    schedule 27.02.2018    source источник
comment
изменение имени столбца с timestamp на tradeTimestamp решает проблему, но возникает другая проблема. нечеткий заказ еще не поддерживается   -  person Chandresh Mishra    schedule 28.02.2018
comment
обновленный запрос: @Query(SELECT * FROM /Trade T WHERE T.stock.symbol =$1 ORDER BY T.tradeTimestamp desc LIMIT 15) нечеткий заказ по еще не поддерживается   -  person Chandresh Mishra    schedule 28.02.2018


Ответы (1)


Проблема не в 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
comment
Спасибо за Ваш ответ. Я понял то же самое после прочтения документации. Кажется, вы достаточно опытны в весенних данных gemfire. Я использую 1.9.10.RELEASE (поскольку я не получил ни одного примера с использованием более высокой версии). Поддерживает ли spring data gemfire сравнение Java 8 LocalDateTime по своей сути? Я хочу получить данные о сделках за последние 15 минут. Не могли бы вы предложить лучший способ добиться этого. - person Chandresh Mishra; 28.02.2018