it-roy-ru.com

Hibernate - @ElementCollection - Странное поведение удаления/вставки

@Entity
public class Person {

    @ElementCollection
    @CollectionTable(name = "PERSON_LOCATIONS", joinColumns = @JoinColumn(name = "PERSON_ID"))
    private List<Location> locations;

    [...]

}

@Embeddable
public class Location {

    [...]

}

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

DELETE FROM PERSON_LOCATIONS WHERE PERSON_ID = :idOfPerson

А также

A lotsa' inserts into the PERSON_LOCATIONS table

Hibernate (3.5.x/JPA 2) удаляет все связанные записи для данного Person и повторно вставляет все предыдущие записи, а также новую.

У меня была идея, что метод equals/hashcode в Location решит проблему, но это ничего не изменило.

Любые советы приветствуются!

38
nihilist84

Проблема как-то объясняется на странице о ElementCollection вики-книги JPA:

Первичные ключи в CollectionTable

Спецификация JPA 2.0 не предоставить способ определения Id в Embeddable. Однако удалить или обновить элемент Отображение ElementCollection, некоторые уникальные ключ обычно требуется. Иначе, при каждом обновлении провайдер JPA будет нужно удалить все из CollectionTable для Entity, и затем вставьте значения обратно. Итак Провайдер JPA, скорее всего, примет что сочетание всех поля в Embeddable являются уникальными, в сочетании с внешним ключом (JoinColunm (ы)). Это, однако, может быть неэффективно, или просто неосуществимо, если Embeddable большой или сложный.

И именно это (часть, выделенная жирным шрифтом) происходит здесь (Hibernate не генерирует первичный ключ для таблицы коллекции и не имеет возможности обнаружить какой элемент коллекции, измененной и удалит старое содержимое из таблицы, чтобы вставить новый контент).

Однако, если вы определяете @OrderColumn (чтобы указать столбец, используемый для поддержания постоянного порядка списка - что будет иметь смысл, поскольку вы используете List), Hibernate создаст первичный ключ ( сделан из столбца order и столбца соединения) и сможет обновлять таблицу сбора, не удаляя весь контент.

Примерно так (если вы хотите использовать имя столбца по умолчанию):

@Entity
public class Person {
    ...
    @ElementCollection
    @CollectionTable(name = "PERSON_LOCATIONS", joinColumns = @JoinColumn(name = "PERSON_ID"))
    @OrderColumn
    private List<Location> locations;
    ...
}

Рекомендации

  • Спецификация JPA 2.0
    • Раздел 11.1.12 «Аннотация ElementCollection»
    • Раздел 11.1.39 «Аннотация колонки заказа»
  • JPA Wikibook
56
Pascal Thivent

В дополнение к ответу Паскаля, вы также должны установить хотя бы один столбец как NOT NULL :

@Embeddable
public class Location {

    @Column(name = "path", nullable = false)
    private String path;

    @Column(name = "parent", nullable = false)
    private String parent;

    public Location() {
    }

    public Location(String path, String parent) {
        this.path = path;
        this.parent= parent;
    }

    public String getPath() {
        return path;
    }

    public String getParent() {
        return parent;
    }
}

Это требование задокументировано в AbstractPersistentCollection :

Обходной путь для ситуаций, подобных HHH-7072. Если элемент коллекции является компонентом, который целиком состоит из Обнуляемые свойства, в настоящее время мы должны принудительно воссоздать всю коллекцию. Смотрите использование для hasNotNullableColumns в конструкторе AbstractCollectionPersister для получения дополнительной информации. Для того, чтобы удалить строка за строкой, для которой требуется SQL, например "WHERE (COL =? OR (COL равен нулю, а? равен нулю))", а не текущий "WHERE COL =?" (сбой для нуля для большинства БД). Обратите внимание, что парам должен быть связан дважды. Пока мы в конечном итоге не добавим понятия "точки привязки параметров" в AST в ORM 5+ обработка этого типа условия либо чрезвычайно сложна, либо невозможна. Принуждение отдых не идеален, но на самом деле нет другого варианта в ORM 4.

7
Vlad Mihalcea

Мы обнаружили, что сущности, которые мы определяли как наши типы ElementCollection, не имели определенного метода equals или hashcode и имели пустые поля. Мы предоставили их (через @lombok, что это стоит) для типа сущности, и это позволило hibernate (v 5.2.14) идентифицировать, что коллекция была или не была грязной.

Кроме того, эта ошибка возникла у нас, поскольку мы находились в методе службы, помеченном аннотацией @Transaction(readonly = true). Поскольку hibernate будет пытаться очистить коллекцию связанных элементов и вставить ее заново, транзакция завершится неудачно, когда произойдет сброс, и что-то будет прерываться с этим очень трудным для отслеживания сообщением:

HHH000346: Error during managed flush [Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1]

Вот пример нашей модели сущности с ошибкой

@Entity
public class Entity1 {
@ElementCollection @Default private Set<Entity2> relatedEntity2s = Sets.newHashSet();
}

public class Entity2 {
  private UUID someUUID;
}

Меняя это на это

@Entity
public class Entity1 {
@ElementCollection @Default private Set<Entity2> relatedEntity2s = Sets.newHashSet();
}

@EqualsAndHashCode
public class Entity2 {
  @Column(nullable = false)
  private UUID someUUID;
}

Исправлена ​​наша проблема. Удачи. 

1
Mustafakidd

У меня была та же проблема, но я хотел отобразить список перечислений: List<EnumType>.

Я получил это работает так:

@ElementCollection
@CollectionTable(
        name = "enum_table",
        joinColumns = @JoinColumn(name = "some_id")
)
@OrderColumn
@Enumerated(EnumType.STRING)
private List<EnumType> enumTypeList = new ArrayList<>();

public void setEnumList(List<EnumType> newEnumList) {
    this.enumTypeList.clear();
    this.enumTypeList.addAll(newEnumList);
}

Проблема со мной заключалась в том, что объект List всегда заменялся с использованием установщика по умолчанию, и поэтому hibernate рассматривал его как полностью «новый» объект, хотя перечисления не менялись.

0
tomasulo