Отсоединенный объект JPA не получает поле версии, заполненное - PullRequest
Новая
       19

Отсоединенный объект JPA не получает поле версии, заполненное

0 голосов
/ 24 февраля 2012

Я использую Roo 1.2.1, JPA 2 и Hibernate 3.6, подключенные к базе данных MSSQL.

У меня есть веб-сервис, который принимает JSON и анализирует его в сущности; очевидно, столбец @Version будет равен 0, потому что человек, вызывающий службу, ничего не знает об этом. Когда я вызываю merge () в первый раз, он работает нормально. Объект сохраняется правильно и столбец версии устанавливается в 1. Но в следующий раз, когда я вызываю веб-сервис с теми же данными, он говорит, что объект устарел, что технически правильно, поскольку версия всегда будет 0.

Идентификатор, который они нам передают, гарантированно будет уникальным, поэтому мы используем его в качестве основного ключа.

Мне бы хотелось подумать, что об этом как-то позаботится менеджер сущностей.

Итак, мой вопрос: как мне справиться с этим, не загружая сначала все сущности из базы данных, затем обновляя поля и затем повторно сохраняя их? Это похоже на взлом; может я об этом неправильно говорю?

Моя сущность выглядит так: 

@RooJavaBean
@RooToString
@RooJson
@RooJpaActiveRecord(table = "MYTABLE", persistenceUnit = "myPersistenceUnit",
    transactionManager = "myTransactionManager", versionField = "version", identifierColumn = "myIdField")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@Entity
public class MyEntity {
  @Id
  @Column(name = "myIdField")
  private long myIdField;

  @Version
  @Column(name = "version")
  private long version;

  @Column("myColumn")
  private String someValue;
}

1 Ответ

1 голос
/ 24 февраля 2012

Вы должны решить, хотите ли вы оптимистическую блокировку или нет.

Если вы хотите обновить базу данных тем, что отправляет клиент, независимо от возможных одновременных обновлений между временем получения объекта и временем его обновления, то это означает, что вам не нужна оптимистическая блокировка,и в сущности не должно быть поля версии.

Если вы хотите оптимистическую блокировку, тогда версия должна быть частью объединенной сущности.Вот как работает механизм: он проверяет, совпадает ли сохраненный номер версии с переданным номером версии.Поэтому, если вы всегда передаете 0, очевидно, что оно никогда не будет работать.

Самый простой способ, конечно, сделать его частью объекта JSON, отправляемого клиентом и от него.Можно также представить сохранение версии данного объекта (отправленной клиенту для будущего обновления, поэтому ключом будет clientId-entityId) в некоторой таблице в памяти или в базе данных, но это будет сложнее реализовать.

...