Hibernate Mapping - таблица соединений без @Id

Question

Hibernate Mapping - таблица соединений без @Id

1

У меня есть три таблицы: Member, Address и Mem_Addr. Mem_Addr Member и Address сопоставлены/связаны таблицей Mem_Addr. Многим многим.

У меня есть следующие лица для Member и Address:

@Entity 
@Table (name="Member")
public class Member{

    @Id  //....
    private Integer mem_id;

    @OneToOne
    @JoinTable     (name = "Mem_Addr", 
             joinColumns = @JoinColumn(name = "addr_id"), 
      inverseJoinColumns = @JoinColumn(name = "mem_id"))
    Set<Address> addresses = new HashSet<Address>;
    ...
}

Таблица Mem_Addr (У него нет связанного объекта).

addr_id // (PK) Sequence
mem_id  // (FK to mem_id in Member table) 
....
....

Address.

@Entity
@Table(name="Address")
public class Address {

   private String addr_id; // Foreign Key to addr_id in Mem_addr table
   private String address1;
   ...
}

У меня нет ID в таблице/сущности Address. (Пожалуйста, не спрашивайте меня о дизайне. Его нельзя изменить сейчас.)

Поэтому, когда я загружаю элементы, я хочу загрузить все адреса для этого члена.

Каково решение?

Изменить: Подробнее...

В основном у некоторых Member будет новая запись в таблице Mem_Addr. Для каждой записи в таблице Mem_addr будет запись в таблице Address.

Чтобы получить адрес члена, мне нужно передать Mem_Addr. Mem_Addr имеет addr_id как первичный, а адрес имеет addr_id как внешний ключ.

Kevin Rave 24 сен. 2014, в 22:15

Источник

1

Есть ли addr_id в сущности Address, потому что я вижу в сущности Mem, которую вы вызываете?
Rika 24 сен. 2014, в 20:03
0

@Rika Рика, ты прав .. Я опечатка. Исправленный.
Kevin Rave 24 сен. 2014, в 20:05
0

Я думаю, что вы, вероятно, можете подключиться без идентификаторов, но это должна быть аннотация Embeddable, см. Здесь stackoverflow.com/questions/767277/hibernate-and-no-pk
Rika 24 сен. 2014, в 20:13
0

@Rika: Я думаю, что подход @Embeddable не сработает, если таблица, которую вы пытаетесь отобразить, является внешним ключом к чему-то другому. Предполагается, что объект Hibernate является независимым, автономным объектом, поэтому Hibernate попытается вставить новую строку в Address , что приведет к сбою из-за неудовлетворенного ограничения FK и будет отменено.
Tim 24 сен. 2014, в 20:25
0

@Tim Вероятно, это может сработать, если он превращает Mem_Addr в сущность, а затем делает String addr_id; в Адрес для MemAddr addr_id; затем сделайте вещь Embeddable, она должна правильно вставить ее с каскадом
Rika 24 сен. 2014, в 20:58
0

Эй, мистер Рэйв, возможно ли превратить Mem_Addr в сущность?
Rika 24 сен. 2014, в 20:59
0

@Rika Рика, да, я могу, если нужно. Я обновил свой вопрос. Пожалуйста, проверьте.
Kevin Rave 24 сен. 2014, в 21:09
0

@Rika Мне не нужно вставлять с этим. Мне просто нужно загрузить адреса вместе с участниками .. Нет вставок или обновлений.
Kevin Rave 24 сен. 2014, в 21:10
0

@Rika Вы правы, было бы возможно отобразить оба класса и использовать @Embeddable для встраивания одного в другой, но вы не должны. Цель Hibernate - позволить вам преодолеть различия между вашей объектной моделью и моделью данных, включая способы, в которых ваша модель данных является неоптимальной из-за унаследованных проблем, как это кажется здесь. Представление сущности для Mem_Addr выявляет несоответствие, а не скрывает его, и связывает объектную модель с плохим дизайном модели данных. Лучшее решение состоит в том, чтобы использовать один класс сущностей (как предполагается для OP) и отобразить в модель данных, используя @SecondaryTable.
Tim 24 сен. 2014, в 21:22
0

Кевин, почему ты изменил это на @OneToOne? Вы действительно это имеете в виду, а не @OneToMany?
Tim 24 сен. 2014, в 21:26
0

@Tim Тим, да. Я действительно это имею в виду.
Kevin Rave 24 сен. 2014, в 21:34
0

Затем вы должны изменить тип на Address вместо Set<Address> , так как однозначные могут иметь только одно связанное значение. Но, основываясь на ваших комментариях (например, «Я хочу загрузить все адреса для этого участника».), Я не верю, что это действительно то, что вы имеете в виду, даже если вы говорите, что это так.
Tim 24 сен. 2014, в 21:40
0

Это радикально меняет любое решение, которое может иметь, если я использую OneToOne против OneToMany?
Kevin Rave 24 сен. 2014, в 21:42
0

Не должно быть большой разницы, если вы используете подход SecondaryTable. Если вы собираетесь использовать подход @Rika's Rika, который не допускает обновления / вставки, я не верю, что вы можете использовать объединяющую таблицу с однозначными значениями, чтобы это имело значение, но поскольку вы не отказываетесь этот путь, вероятно, не имеет значения. Хотя я не уверен, что OneToOne легален для коллекции; Я никогда не пытался это сделать (это семантически неправильно, работает ли это или нет, поэтому я никогда не хотел), поэтому вы можете столкнуться с проблемами, но если вы это сделаете, они должны быть достаточно простыми, чтобы вы могли разобраться.
Tim 24 сен. 2014, в 21:50
0

Хорошо. может быть, я потерян. Какое ваше предлагаемое решение .. Предполагая, что его @OneToMany и оставляя таблицы обновляемыми и вставляемыми?
Kevin Rave 24 сен. 2014, в 21:52
0

Сопоставьте Address субъекта как к Mem_Addr и Address таблиц , используя SecondaryTable аннотацию, как я описал в своем ответе ниже.
Tim 24 сен. 2014, в 21:57
0

Хорошо, позвольте мне проверить, как это можно сделать ..
Kevin Rave 24 сен. 2014, в 22:02
0

Вы когда-нибудь работали? Подход SecondaryTable дал вам то, что вам нужно, или вы в конечном итоге занялись чем-то другим?
Tim 28 сен. 2014, в 17:57
0

@Tim Я пока не пробовал. Я не видел идеальный пример для моего случая в поиске Google!
Kevin Rave 29 сен. 2014, в 15:04

Показать ещё 17 комментариев

Теги:

java

hibernate

oracle

entity

hibernate-onetomany

3 ответа

Ещё вопросы

Есть ли addr_id в сущности Address, потому что я вижу в сущности Mem, которую вы вызываете?
@Rika Рика, ты прав .. Я опечатка. Исправленный.
Я думаю, что вы, вероятно, можете подключиться без идентификаторов, но это должна быть аннотация Embeddable, см. Здесь stackoverflow.com/questions/767277/hibernate-and-no-pk
@Rika: Я думаю, что подход @Embeddable не сработает, если таблица, которую вы пытаетесь отобразить, является внешним ключом к чему-то другому. Предполагается, что объект Hibernate является независимым, автономным объектом, поэтому Hibernate попытается вставить новую строку в Address , что приведет к сбою из-за неудовлетворенного ограничения FK и будет отменено.
@Tim Вероятно, это может сработать, если он превращает Mem_Addr в сущность, а затем делает String addr_id; в Адрес для MemAddr addr_id; затем сделайте вещь Embeddable, она должна правильно вставить ее с каскадом
Эй, мистер Рэйв, возможно ли превратить Mem_Addr в сущность?
@Rika Рика, да, я могу, если нужно. Я обновил свой вопрос. Пожалуйста, проверьте.
@Rika Мне не нужно вставлять с этим. Мне просто нужно загрузить адреса вместе с участниками .. Нет вставок или обновлений.
@Rika Вы правы, было бы возможно отобразить оба класса и использовать @Embeddable для встраивания одного в другой, но вы не должны. Цель Hibernate - позволить вам преодолеть различия между вашей объектной моделью и моделью данных, включая способы, в которых ваша модель данных является неоптимальной из-за унаследованных проблем, как это кажется здесь. Представление сущности для Mem_Addr выявляет несоответствие, а не скрывает его, и связывает объектную модель с плохим дизайном модели данных. Лучшее решение состоит в том, чтобы использовать один класс сущностей (как предполагается для OP) и отобразить в модель данных, используя @SecondaryTable.
Кевин, почему ты изменил это на @OneToOne? Вы действительно это имеете в виду, а не @OneToMany?
@Tim Тим, да. Я действительно это имею в виду.
Затем вы должны изменить тип на Address вместо Set<Address> , так как однозначные могут иметь только одно связанное значение. Но, основываясь на ваших комментариях (например, «Я хочу загрузить все адреса для этого участника».), Я не верю, что это действительно то, что вы имеете в виду, даже если вы говорите, что это так.
Это радикально меняет любое решение, которое может иметь, если я использую OneToOne против OneToMany?
Не должно быть большой разницы, если вы используете подход SecondaryTable. Если вы собираетесь использовать подход @Rika's Rika, который не допускает обновления / вставки, я не верю, что вы можете использовать объединяющую таблицу с однозначными значениями, чтобы это имело значение, но поскольку вы не отказываетесь этот путь, вероятно, не имеет значения. Хотя я не уверен, что OneToOne легален для коллекции; Я никогда не пытался это сделать (это семантически неправильно, работает ли это или нет, поэтому я никогда не хотел), поэтому вы можете столкнуться с проблемами, но если вы это сделаете, они должны быть достаточно простыми, чтобы вы могли разобраться.
Хорошо. может быть, я потерян. Какое ваше предлагаемое решение .. Предполагая, что его @OneToMany и оставляя таблицы обновляемыми и вставляемыми?
Сопоставьте Address субъекта как к Mem_Addr и Address таблиц , используя SecondaryTable аннотацию, как я описал в своем ответе ниже.
Хорошо, позвольте мне проверить, как это можно сделать ..
Вы когда-нибудь работали? Подход SecondaryTable дал вам то, что вам нужно, или вы в конечном итоге занялись чем-то другим?
@Tim Я пока не пробовал. Я не видел идеальный пример для моего случая в поиске Google!

Rika · Answer 1 · 2014-09-24T19-56-00.000Z

Ладно, поскольку вставки и обновления не нужны, возможно, должно работать следующее (теоретически):

@Entity
@Table(name = "Address")
class Address {

 @Id
 private AddressKey id;

 public void setId(AddressKey id) {
 this.id = id;
 }

 public void getId() {
 return id;
 }
}

а также

@Embeddable
class AddressKey implements Serializable {
   @Column(name = "addr_id")
   private String addrId; //also the underscore should be deleted

   @Column(name = "address_1")
   private String address1;



  }

Это временное решение для таблиц, которые не имеют первичных ключей. Как вы можете видеть, это в значительной степени делает фальшивый идентификатор.

Если мы не беспокоимся о вставках и обновлениях, зачем беспокоиться о @Embeddable? Просто сопоставьте addr_id как @Id и покончите с этим. (Кроме того, address1 не является частью первичного ключа таблицы, поэтому я не уверен, почему вы включили его в @Embeddable ...)
Но как вы сопоставляете таблицу Address to Members. Между этими двумя нет никакой связи. Это может быть простая вещь .. .. вы меня понимаете .. Я новичок в Hibernate :-)
Для справки, однако, я думаю, что это плохое решение намеренно отображать объект Hibernate, который нельзя использовать для записи в базу данных, даже если вы думаете, что вам не нужна эта способность. Скорее всего, в какой-то момент вы это сделаете, и даже если они действительно вам никогда не понадобятся в работе, что если вы захотите записать некоторые тестовые данные в фиктивную базу данных для использования в модульных тестах? Я думаю, что использование этого подхода было бы ошибкой, когда другие подходы также будут работать и не будут иметь этих недостатков, но мы все делаем свой выбор, так что это ваш вызов.
@ Тим, это хороший момент. Может быть, мне нужно разрешить вставки и обновления. Я пойду с этим.

Tim · Answer 2 · 2014-09-24T18-11-00.000Z

1

Вы уверены, что таблица Mem_Addr - это много-ко-многим, а не один-ко-многим? Я не вижу, как один Address может быть связан с более чем одним Member...

Предполагая, что это на самом деле один-ко-многим, сопоставить Address субъекта к обоим Mem_Addr и Address таблиц через @SecondaryTable аннотацию, как описано в Hibernate Mapping двух таблиц в одном классе, отображение идентификатора Mem_Addr.addr_id, на Member с помощью Mem_Addr.mem_id, и все остальное через другие поля в Address.

Я этого не делал, но считаю, что это сработает:

@Entity
@Table(name = "Address")
@SecondaryTable(name = "Mem_Addr", pkJoinColumns={
    @PrimaryKeyJoinColumn(name="addr_id" referencedColumnName="addr_id")
})
class Address {
    @Id
    @Column
    private String addr_id;

    ....
}

Tim 24 сен. 2014, в 18:11

0

Это возможно. Потому что в страховом домене несколько клиентов могут быть по одному адресу. Хорошо, если я предполагаю, что это будет @OneToMany, но ваше решение неясно. Можете ли вы уточнить?
Kevin Rave 24 сен. 2014, в 20:30
0

Я этого не делал (к счастью, у меня всегда были схемы, которые были более разумными, чем то, с чем вы застряли), но вы должны иметь возможность использовать для этого аннотацию @SecondaryTable, как описано в stackoverflow.com/questions/ 1667918 /… .
Tim 24 сен. 2014, в 20:43
0

Кроме того, я согласен с тем, что в реальном мире можно иметь несколько Member для одного Address . Но я не верю, что это возможно в вашей схеме базы данных (вам нужно создать один объект Address для каждого объекта Member , даже если значения этого Address будут одинаковыми), поэтому, надеюсь, вам будет позволено изменить эту схему в какой-то момент в будущем.
Tim 24 сен. 2014, в 20:46
0

Хорошо. Я обновляю свой вопрос с большим пониманием. Я думаю, что это может привести к другому решению от вас. :-).
Kevin Rave 24 сен. 2014, в 20:51
0

Я обновил свой вопрос. Пожалуйста, проверьте..
Kevin Rave 24 сен. 2014, в 21:11
0

Ничто из того, что вы добавили, не меняет решение здесь. Поскольку первичный ключ находится в таблице Mem_Addr , класс Address должен быть сопоставлен с ним, но он также должен быть сопоставлен с таблицей Address . Чтобы сопоставить один класс двум таблицам, вы должны будете использовать @SecondaryTable, как я и предлагал.
Tim 24 сен. 2014, в 21:16

Показать ещё 4 комментария

Peter Pei Guo · Answer 3 · 2014-09-24T18-02-00.000Z

К сожалению, пути нет, Hibernate требует, чтобы ваша таблица имела первичный ключ.

Вы можете проверить этот документ.