Блог

Главная - Вопросы по программированию - Каков правильный подход к денежным операциям с JPA MySQL?

Каков правильный подход к денежным операциям с JPA MySQL?

#jpa #spring-data-jpa #spring-data #bigdecimal

Вопрос:

У меня есть случай, когда мне нужно выполнить обновление в поле, в котором в данном случае выполняется вычитание денежной операции. Столбец был создан как 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);

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

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

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

Хранилище:

     @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.

Какой правильный подход использовать все в качестве больших десятичных, даже параметры NativeQuery?

Ответ №1:

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

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

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

Метки: