powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Мэппинг для однонаправленной связи
48 сообщений из 48, показаны все 2 страниц
Мэппинг для однонаправленной связи
    #38020864
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть две сущности
Например Employer и Phone (пример из Pro JPA 2).
Employee 1 ------------> * Phone
Employe знает про Phone, а Phone про Employe не знает.
Что это собственно значит в понятиях классов?
Что в классе Employee есть List<Phone> phone но в классе Phone нет поля Employee?

Цитата
"There is no join column to store the association back from
Phone to Employee. Therefore, we have used a join table to associate the Phone entity with the Employee
entity."
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38020875
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oson,
да, для соединения используется еще одна таблица, поэтому в классе телефона не нужно поле сотрудник
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38020882
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ok, спасибо.

такой нюанс. А зачем вообще делать таким образом однонаправленную связь - не то же самое получиться, если например сделать обычный мэппинг с @OneToMany(mappedBy = "employee"), то есть у Phone будет поле employee, но просто оставить его приватным,
то есть никаких setEmploye()/getEmployee(). Разве не то же самое получиться? В чем будет отличие?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38020905
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oson,
ну во первых, обычный мэппинг, как вы его называете:@OneToMany(mappedBy = "employee") не такой уж и обычный. Это скорее отсутствие мэппинга. Хибернейт не понимает двунаправленных связей. mappedBy это указание, чтобы он не создавал вторую связь Employe-Phone. Потому что она уже замаплена в Phone. Если вам нужны телефоны в классе сотрудника, но не нужна ссылка на сотрудника в классе телефон, то в телефоне просто ничего не указывайте про связь с сотрудником, а в сотруднике сделайте так:
Код: java
1.
2.
@OneToMany
@JoinColumn(name = "emp_id")


При этом хибер в таблице телефона создаст колонку emp_id, которая будет использоваться для связи с сотрудником, дополнительную таблицу для связи создавать не будет, и доступа из класса телефона к этому полю тоже не будет. Если я правильно понял, это то что вам надо. Я далеко не гуру Хибернейта, поэтому на истину в последней инстанции не претендую. Есть хороший туториал индуса на ломаном английском, но от этого не менне ценный. Очень рекомендую.
http://www.youtube.com/watch?v=Yv2xctJxE-w&list=PL4AFF701184976B25&feature=plpp_play_all
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38020909
Фотография grasoff.net
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckeroson,
ну во первых, обычный мэппинг, как вы его называете:@OneToMany(mappedBy = "employee") не такой уж и обычный. Это скорее отсутствие мэппинга. Хибернейт не понимает двунаправленных связей. mappedBy это указание, чтобы он не создавал вторую связь Employe-Phone. Потому что она уже замаплена в Phone. Если вам нужны телефоны в классе сотрудника, но не нужна ссылка на сотрудника в классе телефон, то в телефоне просто ничего не указывайте про связь с сотрудником, а в сотруднике сделайте так:
Код: java
1.
2.
@OneToMany
@JoinColumn(name = "emp_id")



При этом хибер в таблице телефона создаст колонку emp_id, которая будет использоваться для связи с сотрудником, дополнительную таблицу для связи создавать не будет, и доступа из класса телефона к этому полю тоже не будет. Если я правильно понял, это то что вам надо. Я далеко не гуру Хибернейта, поэтому на истину в последней инстанции не претендую. Есть хороший туториал индуса на ломаном английском, но от этого не менне ценный. Очень рекомендую.
http://www.youtube.com/watch?v=Yv2xctJxE-w&list=PL4AFF701184976B25&feature=plpp_play_all
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021187
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
osonEmployee 1 ------------> * Phone

такая связь обозначает подчинённую таблицу с телефонами с каскадным удалением оных при удалении сотрудника (обычно по смыслу и БЛ)

Код: java
1.
2.
3.
4.
5.
6.
7.
public class Book {
	@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy = "id_book", targetEntity = Comment.class)
	private List<Comment> comments;
	
public class Comment {
  @ManyToOne()
  private Book id_book;



в РСУБД

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
create table Book (
        id  bigserial not null,
        Name varchar(255) not null,

        primary key (id)
    )

    create table Comment (
        id  bigserial not null,
        id_book_id int8,
        MyName varchar(255) not null,

        primary key (id)
    )

    alter table Comment 
        add constraint FK9BDE863FC891AF2 
        foreign key (id_book_id) references Book



т.е. конечная цель маппинга - получить или "договориться" с РСУБД на такие таблицы с данными и связями\действиями (как каскад)
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021230
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123, ТС хотел чтобы phone не знал об employe, поэтому @ManyToOne не надо, ну и mappedBy соответственно тоже.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021246
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123, ТС хотел чтобы phone не знал об employe, поэтому @ManyToOne не надо, ну и mappedBy соответственно тоже.
мне интересен этот вариант. Он жизненнен вообще?
Распиши классы и, главное! - SQL DDL
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021297
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
классы:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
public class Book {
   @Id
   private Long id;

   @OneToMany()
   @JoinColumn(name = "book_id")
   private List<Comment> comments;
	
public class Comment {
  @Id
  private Long id;
  }



DDL:

book
id (PK)

comment
id (PK)
book_id (FK->book.id)
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021308
Фотография grasoff.net
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Он жизненнен вообще?да, с небольшими поправками )
redhat, например, не рекомендует
jpa1, например, такое не рекомендует
мир делится в этом смысле на две части - первая не рекомендует, вторая недоумевает, почему первая не рекомендует

ps я во второй )
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021324
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
вот смотри какая штука.
Твой вариант, действительно есть в маппинге и жизни (их всего 2).
Но, ситуация кардинально меняется отношением к таблице Комментарии (Телефоны).
Она из подчинённой, удаляемой по каскаду вместе с сотрудником, стала главной и неудаляемой.
А книжка или сотрудник стали справочной таблицей к этой по FK.
Это кардинальное различие в двух маппингах и моделях жизненных ситуаций.

По ТС я вижу, что телефоны надо удалять, значит каскад, значит IMHO мой вариант выше.
ЗЫ.
В access субд )))) есть понятие подчинённая таблица с каскадом и справочная с FK.
В других СУБД по другому называется.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021327
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
grasoff.net,

я считаю, что РСУБД главнее хибера))
Поэтому я вообще тут отдельно)))
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021328
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
grasoff.net,

ну вообще такая связь, когда коммент однозначно имеет смысл только для какой-то одной книги и без нее существовать не может, или аналогично с сотрудниками - телефонами, проще реализуется коллекцией.
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
@Entity
public class Book {
   @Id
   private Long id;

   @ElementCollection
   private List<Comment> comments;

@Embedded	
public class Comment {
   private String cmnt;
  }
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021335
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123, ну тут каскад никто не мешает поставить
Код: java
1.
2.
3.
   @OneToMany(cascade...)
   @JoinColumn(name = "book_id" )
   private List<Comment> comments;
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021340
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerкогда коммент однозначно имеет смысл только для какой-то одной книгиэто 1 к 1 и оффтоп
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021345
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123, ну тут каскад никто не мешает поставить
Код: java
1.
2.
3.
   @OneToMany(cascade...)
   @JoinColumn(name = "book_id" )
   private List<Comment> comments;


тогда не понял разницы, если DDL твой и мой одинаков.
Кстати, проверь - работает каскад?

Я про то что есть 2 варианта бизнес-логики и маппинга
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021363
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
это 1 к 1 и оффтоп Не один к одному, а один ко многим. Одна книга - много коментов. Но каждый комент имеет смысл только для одной книги, его нельзя присобачить к другой и он не может существовать отдельно от книги. Тогда нужно использовать коллецию элементов и не делать комент самостоятельной сущностью.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021385
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123,
это 1 к 1 и оффтоп Не один к одному, а один ко многим.
Одна книга - много коментов. Но каждый комент имеет смысл только для одной книги, его нельзя присобачить к другой и он не может существовать отдельно от книги. Тогда нужно использовать коллецию элементов и не делать комент самостоятельной сущностью.
хорошо бы привести DDL но мы утонем в данном случае. Часто для телефона удобнее именно сущность и отдельная таблица.
Поэтому IMHO Embedded лучше не рассматривать.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021446
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
мы запутались в терминологии. Щас перефразирую. Если использовать для телефонов коллекцию эмбед элементов, то с точки зрения приложения это все равно сущность - такой же класс как и был. С точки зрения базы - это отдельная таблица, не имеющая в общем случае суррогатного первичного ключа и имеющая фк на сотрудника. То есть хибер не позволит выбрать из базы телефоны и сохранить их туда отдельно. Только вместе с сотрудником, которому они принадлежат. Таким образом, весь жизненный цикл телефона полностью контролирует сотрудник. Удаляем сотрудника - удаляются телефоны. Никаких каскадов руками писать не нужно, никакие другие классы не могут иметь ссылку на телефон. Думаю, что это правильно. Щас поэкскрементирую и выложу результаты каскада и ддл для всего этого добра.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021472
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
ок. Только давай тогда 3 варианта и так как выложил я (классы-dll-пример заполнения БД - хинт таблица для форума)

1. Мой вариант (главная-Сотрудник с каскадом)

2. вариант СПРАВОЧНИК (главная табла -Телефонный справочник без удаления). FK только для целостности и допускаются висящие телефоны без сотрудников.

3. Embedded

Это разные варианты именно по бизнесу от БА
______________________________________________
"Сделай настолько просто, насколько это возможно, но не проще". © А. Эйнштейн.
AutoPOI.ru — ГИС-технологии для Oracle
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021482
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
что это?
хинт таблица для форума
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021499
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,

HTML табличка с примерами данныз в БД для ТС женского пола))
типа такой
Заголовок#IDjavapecker
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021505
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
У меня просто скрин был. Поэтому я привёл скрин.
Удачи!
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021574
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,

вариант СПРАВОЧНИК (главная табла -Телефонный справочник без удаления). FK только для целостности и допускаются висящие телефоны без сотрудников. Я не понимаю зачем так извращен этот вариант. Он от первого ничем не отличается, кроме того, что телефон не знает ничего о сотруднике. Висячие телефоны прекрасно работают и в первом варианте и в этом. Каскад работает как в первом так и во втором варианте. Не понимаю почему вдруг таблица телефонов стала главной.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021652
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123,

вариант СПРАВОЧНИК (главная табла -Телефонный справочник без удаления). FK только для целостности и допускаются висящие телефоны без сотрудников. Я не понимаю зачем так извращен этот вариант. Он от первого ничем не отличается, кроме того, что телефон не знает ничего о сотруднике. Висячие телефоны прекрасно работают и в первом варианте и в этом. Каскад работает как в первом так и во втором варианте. Не понимаю почему вдруг таблица телефонов стала главной.
висячие телефоны в первом варианте НЕ допускаются, т.к. ОНИ НЕ НУЖНЫ БИЗНЕСУ.
Это не справочник городов или улиц. Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021657
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerНе понимаю почему вдруг таблица телефонов стала главной.
если в ТЗ вместо Телефона - Адрес, то БА может задать требования и делаем Модель по варианту 2
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021719
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
Я спрашиваю, почему в своем варианте ты называешь главной таблицу сотрудников, а во втором варианте главной - таблицу телефонов? База одинаковая в одном и другом случае. В приложении разница только в том, что в телефоне нет ссылки на сотрудника. В коде который ты выложил нет никаких ограничений, которые запретили бы создавать висячий телефон. В моем варианте их тоже нет, но если сделать так в твоем:
Код: java
1.
2.
    @ManyToOne(optional=false)
    private Book book;


или так в моем:
Код: java
1.
2.
3.
 @OneToMany(cascade= CascadeType.ALL)
    @JoinColumn(name = "book_id",nullable=false)
    private List<Comment> clist = new ArrayList<>();


то ты не сможешь сохранять сиротливые телефоны и там и там. И все.
по поводу этого:
Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?
См. выше - установи ограничения. Есть они или нет - они одинаково работают для первого и второго варианта. Ну и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника? я нигде не буду пользоваться номером отдельно от сотрудника. И у меня навигация будет всегда от сотрудника к телефону, но не наоборот. Поэтому - второй вариант. И в твоем и в моем варианте связью нужно управлять, эмбед позволяет это делать автоматически без использования каскада. Поэтому еще лучше - третий вариант, потому что он гарантирует, что сиротливых телефонов не будет и они всегда будут синхронизированы с сотрудником.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021762
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
не понятно, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели?

Возьми Access и посмотри.
Один ко многим:
1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо)
2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные)

Будет 2 модели по Бизнесу, а также разный ГУИ!
ОК?

PS/ Каскад решает очень многое.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021771
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
давай, сделай примерчики, и завтра поковыряем демки и генерацию схемы хибером.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021784
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123, сделал под нетбинс 7.2+Postgres. В первых двух случаях схема генерится одинаковая. Висячие телефоны сохраняются. С добавлением optional = false или nullable = false не сохраняются. В третьем случае для телефона генерится таблица без первичного ключа с фк на сотрудника. Выложить проекты?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021789
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerНу и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника?
afaik на rsdn чел мучился именно с каскадом.
У него не выходило именно без этой ссылки.
Попробуй и выложи минимальный с каскадом для 1-го варианта.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021793
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
проекты не надо. Лучше как выше написал:
1. Каскад без висячих
2. без каскада + висячие само собой
3. без PK
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021794
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021833
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123,
почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов.
ок.
Давай свой вариант, только проверь каскад и отсутствие висячих (мне именно это надо было)
Для сабжа и ТС это будет идеальный вариант. Ведь так?
И закроем тему)
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021834
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,

автор1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо)
2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные)


Если у меня фигурирует заказ самостоятельно где-то , например я получаю список заказов , и для каждого заказа хочу посмотреть к какому сотруднику он относится, мне ЕСТЕСТВЕННО ПОНАДОБИТСЯ ССЫЛКА на сотрудника в заказе. Тут вопрос не в том, могут существовать сиротливые заказы или нет и кто главный, и однозначно, в обоих случаях только твой первый вариант. Второй вариант подойдет для случая когда мне не нужно из заказа тянуть сотрудника. Для заказа это маловероятная ситуация, а вот для телефона самое оно. Потому что вполне у меня может быть список сотрудников, я выберу конкретного сотрудника и посмотрю его телефоны. При этом наоборот мне не надо, то есть я не хочу получать список телефонов, открывать телефон и смотреть чей он.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021836
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
Для сабжа и ТС это будет идеальный вариант
или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021844
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapeckerPetro123,
Для сабжа и ТС это будет идеальный вариант
или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться
да. Я говорил, что редко бывает, т.к. часто ссылаются и табла разрастается до сущности.
Но как пример в 1 проценте случаев - согласен. Тут ТС'ше выбирать )))
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021926
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
Тут ТС'ше
А с чего ты взял что ТС женского пола?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38021940
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
off
ну, если она возмутится, то скажу))
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022001
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
тесты интересные:

В первом варианте нужно обязательно перед сохранением установить в коменте книгу, а в книге добавить этот комент, иначе срабатывает ограничение нот нулл на фк. Потом сохраняем книгу - каскадом сохраняется и комент. Хибер делает два инсерта.

Во втором варианте книге добавляем комент и сохраняем книгу. Каскадом сохраняется и комент. Хибер делает два инсерта и один апдейт комента.
Так что, поведение все-таки не совсем одинаковое.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022049
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
javapecker,
да.
много чего разного.
Хотя скажу, чисто по БД, то при варианте "Справочник Городов\Адресов\Телефонов - главный" - делается внешний ключик FK и направление связи меняется.
т.е.
Один город в виде его Id в таблицу-класс Сотрудник.
Но это вроде оффтоп.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022085
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,
согласен, а как определить кто главный если это например сотрудники и автомобили в связи один ко многим? Сотрудник содержит список авто, авто содержит ссылку на сотрудника. По условию одно авто может быть привязано только к одному сотруднику в один момент времени. а у сотрудника может быть сколько хочешь авто одновременно. Авто может вполне быть не занято, сотрудник может не иметь ни одного авто. При удалении сотрудника я не имею права удалять авто, и наоборот. Но, при удалении сотрудника, я обязан почистить ссылки на него у всех его авто. А при удалении авто я обязан удалить его из списка сотрудника, который на нем ездил. По-моему тут равноправие. Вопрос, как чистисть ссылки?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022129
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
off
javapecker,
начать от печки, т.к. БА вводит понятие время (твоё - "в один момент времени")
Т.е. переход на классику много ко много и промежуточная таблица в виде "Документ-текущийАвтомобиль".
Т.е. незанятое авто, у которого просрочен или снята галка в Документе выше.

Ссылки чистить процедурами Бизнес-слоя "ЗаключитьКонтракт" \ АннулироватьКонтракт.
При аннулировании можешь стереть запись или отправить в архив или (спроси у БА)
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38022685
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?Да.
А почему это так удивляет?
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024194
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так а по существу вопроса?


Есть мэппинг двух сущностей

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    @ManyToOne
    @JoinColumn(name = "BOOK_ID")
    private Book book;
}


@Entity
@Table(name = "BOOKS")
public class Comment
{
    @OneToMany(mappedBy = "book")
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}



То есть я не хочу, чтобы из Comment был доступ к его соотв Book.
Поэтому у меня нет в классе Comment - setBook()/getBook().
В данном случае будет же тот же самый результат, как если бы я убрал

Код: java
1.
2.
 @ManyToOne
    @JoinColumn(name = "BOOK_ID")



из класса Comment. Разве нет?
Но просто ж не будет создаваться дополнительная промежуточная таблица.
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024199
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сорри, ошибка
Правильно

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    @ManyToOne
    @JoinColumn(name = "BOOK_ID")
    private Book book;
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @OneToMany(mappedBy = "book")
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024233
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oson,
по существу вам был дан рабочий код.
Хибер и маппинг подстраивается под РСУБД, а не наоборот.
Поэтому будьте добры включите генерацию БД хибером и протестируйте свой код (классы -- маппинг --DDL --main{})
...
Рейтинг: 0 / 0
Мэппинг для однонаправленной связи
    #38024422
javapecker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oson, По существу мы чуть не подрались из-за вашего вопроса. А вы опять все перепутали. Давайте по порядку. Ваш вопрос был о том, как лучше замапить книги и коменты так, чтобы коменты о книгах не знали, и доп. таблицу хибер не создал. Рассмотрим ваш вариант из последнего поста.
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    @ManyToOne
    @JoinColumn(name = "BOOK_ID")
    private Book book;
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @OneToMany(mappedBy = "book")
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}



Еще раз напомню, что значит mappedBy. Это указание хиберу, что там где стоит мапед бай, свзяь мапить не надо, что эта связь уже замаплена на другом конце связи. В вашем случае не стороне комента уже стоит @ManyToOne. А теперь подумайте. Если связь замаплена со стороны комента, то и задавать ее надо со стороны комента. А вы убрали геттеры и сеттеры оттуда. Как теперь вы зададите, к какой книге относится комент? Петро был прав, когда посоветовал вам сделать маленькие проекты и потестить их, тогда все сразу станет видно. Таким образом, остаются два варианта:
1. Использовать связь только со стороны книги:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
@Entity
@Table(name = "COMMENTS")
public class Comments
{
    //здесь вообще не задана связь с книгой, комент ничего про книгу не знает
    String comment;
    
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @OneToMany()//вся связь замаплена в этом классе
    @JoinColumn(name = "BOOK_ID",nullable = false)    
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}


2. Если у вас не будет больше в модели никаких сущностей, которые будут ссылаться на коменты (кроме книг), вы можете представить коменты как коллекцию компонентов класса книги. Мапится так:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
@Embeddable
@Table(name = "COMMENTS")
public class Comments
{
    //здесь вообще не задана связь с книгой, комент ничего про книгу не знает
//если не предпринимать специальные меры
    String comment;
    
}


@Entity
@Table(name = "BOOKS")
public class Book
{
    @ElementCollection //для 4-го хибера, в третьем вроде  @CollectionOfElements
    private List<Comment> comments;

    public List<Comment> getComments() {}
    public void setComments(List<Comment>) {}
}


В таком случае, ответственность за коменты полностью лежит на книге. Нельзя сохранить сиротливый комент, при удалении книги все коменты удаляются.
...
Рейтинг: 0 / 0
48 сообщений из 48, показаны все 2 страниц
Форумы / Java [игнор отключен] [закрыт для гостей] / Мэппинг для однонаправленной связи
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]