Отношения Hibernate/JPA «многие ко многим» через таблицу соединений и составной ключ, проблема с уникальным ограничением

Итак, я задал этот вопрос вчера, но цели изменились, и вопрос другой:

Коллекция элементов Hibernate/JPA с отношением "многие ко многим"?

Я хочу знать, возможно ли создавать объекты, которые будут моделировать требуемые отношения, чтобы Hibernate создавал мою схему при запуске приложения.

Отношения, которые я хочу, выглядят так:

http://a8.sphotos.ak.fbcdn.net/hphotos-ak-ash4/417593_10150594114269218_505554217_8657377_1475865815_n.jpg

Дело в том, что таблица соединений может фактически содержать строки, которые не ссылаются ни на какие элементы. Структура представляет собой категоризацию элементов на основе пары «тип» и «значение» и вводится в систему вне данного конкретного приложения.

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

Вот что у меня получилось: отобразить это в моем классе Element Entity следующим образом:

@ManyToMany(fetch = FetchType.EAGER)
@JoinTable(name = "ELEMENT_ELEMENTCATOGORY", joinColumns = {
        @JoinColumn(name = "type", referencedColumnName = "type"),
        @JoinColumn(name = "value", referencedColumnName = "value") })
@Column(name = "category")
public List<ElementCategory> getCategories() {
    return categories;
}

Это делает большую часть того, что я хочу, он создает мои таблицы, как указано выше, именно так, как я хочу, чтобы они исключали одну вещь, в таблицу элементов добавлено уникальное ограничение для пары (тип, значение). Я не хочу этого, потому что несколько элементов могут иметь одинаковую пару типа и значения, мне нужно иметь возможность остановить создание уникального ограничения, но не могу понять, как с текущим сопоставлением, могу ли я это сделать? Я упускаю смысл отношения «многие ко многим»?


java hibernate many-to-many unique-constraint composite-key
person Link19    schedule 10.02.2012    source источник
comment
Я все еще думаю, что вам нужен inverseJoinColumn, чтобы включить идентификатор ElementCategory в вашу таблицу соединений.   -  person bvanvelsen    schedule 10.02.2012
comment
Может быть, звучит более логично, что тип и значение являются сущностью? таким образом, идентификатор этого типа, объект значения является соединением столбца соединения.   -  person bvanvelsen    schedule 10.02.2012
comment
Идентификатор подразумевается тем, что у меня есть набор категорий элементов, как и в любом наборе. Как я уже сказал, таблицы настроены правильно, включая связь между категорией в таблице соединений и идентификатором в таблице ElementCategory. Считаете ли вы, что обратное соединение удалит уникальное ограничение из таблицы элементов? Я попытаюсь.   -  person Link19    schedule 10.02.2012
comment
Я просто мысли вслух :)   -  person bvanvelsen    schedule 10.02.2012
comment
Кроме того, вы правы, смоделировать пару типа и значения как Entity более логично, но я не могу изменить таблицу Element, потому что есть внешний интерфейс, доступ к которому я не могу контролировать.   -  person Link19    schedule 10.02.2012
comment
Добавлено в Inverse Join, это не имело никакого эффекта.   -  person Link19    schedule 10.02.2012
comment
давайте продолжим это обсуждение в чате   -  person bvanvelsen    schedule 10.02.2012

Ответы (1)


arrow_upward
1
arrow_downward

На самом деле кажется вполне логичным, что Hibernate накладывает уникальное ограничение на столбец типа и значения.

Вы говорите в отображении @ManyToMany, что в объединении столбцы соединения являются столбцом типа и значения. Таким образом, вы говорите, что hibernate должен определять, какой элемент связан с ElementCategory по свойству value и type. поэтому комбинация этих двух свойств должна быть уникальной. В противном случае hibernate не знал бы, какой элемент принадлежит какому типу элемента.

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

person bvanvelsen    schedule 10.02.2012
comment
Но тогда не было бы никакого способа, чтобы класс Element содержал список категорий? Это просто невезение, потому что ему нужен лучший дизайн? - person Link19; 13.02.2012
comment
он может содержать список категорий, но не на основе типа и значения, если эти 2 значения не уникальны для каждого элемента. - person bvanvelsen; 13.02.2012
comment
Точно, но в моей модели категории основаны на сочетании типа и значения, и несколько элементов МОГУТ иметь одну и ту же пару, поэтому я не могу позволить спящему режиму управлять этим? лучшее, что я могу сделать, это реализовать некоторые функции в моем сервисе, которые работают с категориями отдельно, и сделать список временным. - person Link19; 13.02.2012