У меня есть случай, когда мне нужно выполнить обновление в поле, выполняя денежную операцию вычитания в этом случае. Столбец был создан как DECIMAL(19,2) UNSIGNED.

Сначала я получаю значение:

static final String LOCK_AMOUNT_FOR_UPDATED = "select amount from Sample where uuid = :uuid for update ";

Это репозиторий:

    @Query(value = LOCK_AMOUNT_FOR_UPDATED, nativeQuery = true)
    Float getAmountForUpdate(@Param("uuid") String uuid);

Вот первый вопрос, вместо того, чтобы возвращать Float. Рекомендуемое возвращает BigDecimal?

Затем я проверяю значения и выполняю обновление:

static final String DECREASE_AMOUNT = "update Sample set amount = amount - :amountToSubtract where uuid = :uuid ";

Repository :

    @Modifying
    @Query(value = DECREASE_AMOUNT, nativeQuery = true)
    void decreaseAmount(@Param("amountToSubtract") Float amountNegotiated, @Param("uuid") String uuid);

Это делается при значении: 1927369.70. Я получаю:

Data truncation: Out of range value for column 'amount' at row 1

Вызов метода выглядит так:

repository.decreaseNetAmount(amountNegotiated.floatValue(), uuid);

Я заметил, что 1927369.70 превратился в 1927369.80, когда я выбираю значение и когда я вызываю .floatValue() в BigDecimal.

Какой правильный подход использовать все как BigDecimal, даже параметры nativeQuery?

0
Guilherme Bernardi 18 Май 2021 в 18:03

1 ответ

Лучший ответ

Я бы рекомендовал:

  1. Используйте BigDecimal для параметров и атрибута объекта (если вы решили использовать BigDecimal).
  2. Еще раз подумайте, почему вы используете собственный запрос для обновления одной записи. Получение объекта сущности и изменение значения атрибута кажется более простым подходом и может обеспечить лучшую производительность за счет внутренней оптимизации вашего поставщика сохраняемости.
  3. Еще раз подумайте о пессимистической блокировке, которую вы установили при получении записи. Это также блокирует все операции чтения этой записи (и, возможно, других записей на той же странице) до конца транзакции. Оптимистическая блокировка часто обеспечивает лучшую масштабируемость.

Рекомендации 2 и 3 являются общими передовыми методами. Нам нужно будет шире взглянуть на весь вариант использования и другие части приложения, чтобы принять обоснованное решение.

1
Thorben Janssen 19 Май 2021 в 05:52