|
|
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Есть две сущности Например 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." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2012, 23:23:48 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
oson, да, для соединения используется еще одна таблица, поэтому в классе телефона не нужно поле сотрудник ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2012, 23:39:16 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Ok, спасибо. такой нюанс. А зачем вообще делать таким образом однонаправленную связь - не то же самое получиться, если например сделать обычный мэппинг с @OneToMany(mappedBy = "employee"), то есть у Phone будет поле employee, но просто оставить его приватным, то есть никаких setEmploye()/getEmployee(). Разве не то же самое получиться? В чем будет отличие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2012, 23:50:31 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
oson, ну во первых, обычный мэппинг, как вы его называете:@OneToMany(mappedBy = "employee") не такой уж и обычный. Это скорее отсутствие мэппинга. Хибернейт не понимает двунаправленных связей. mappedBy это указание, чтобы он не создавал вторую связь Employe-Phone. Потому что она уже замаплена в Phone. Если вам нужны телефоны в классе сотрудника, но не нужна ссылка на сотрудника в классе телефон, то в телефоне просто ничего не указывайте про связь с сотрудником, а в сотруднике сделайте так: Код: java 1. 2. При этом хибер в таблице телефона создаст колонку emp_id, которая будет использоваться для связи с сотрудником, дополнительную таблицу для связи создавать не будет, и доступа из класса телефона к этому полю тоже не будет. Если я правильно понял, это то что вам надо. Я далеко не гуру Хибернейта, поэтому на истину в последней инстанции не претендую. Есть хороший туториал индуса на ломаном английском, но от этого не менне ценный. Очень рекомендую. http://www.youtube.com/watch?v=Yv2xctJxE-w&list=PL4AFF701184976B25&feature=plpp_play_all ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 00:20:05 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckeroson, ну во первых, обычный мэппинг, как вы его называете:@OneToMany(mappedBy = "employee") не такой уж и обычный. Это скорее отсутствие мэппинга. Хибернейт не понимает двунаправленных связей. mappedBy это указание, чтобы он не создавал вторую связь Employe-Phone. Потому что она уже замаплена в Phone. Если вам нужны телефоны в классе сотрудника, но не нужна ссылка на сотрудника в классе телефон, то в телефоне просто ничего не указывайте про связь с сотрудником, а в сотруднике сделайте так: Код: java 1. 2. При этом хибер в таблице телефона создаст колонку emp_id, которая будет использоваться для связи с сотрудником, дополнительную таблицу для связи создавать не будет, и доступа из класса телефона к этому полю тоже не будет. Если я правильно понял, это то что вам надо. Я далеко не гуру Хибернейта, поэтому на истину в последней инстанции не претендую. Есть хороший туториал индуса на ломаном английском, но от этого не менне ценный. Очень рекомендую. http://www.youtube.com/watch?v=Yv2xctJxE-w&list=PL4AFF701184976B25&feature=plpp_play_all ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 00:27:23 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
osonEmployee 1 ------------> * Phone такая связь обозначает подчинённую таблицу с телефонами с каскадным удалением оных при удалении сотрудника (обычно по смыслу и БЛ) Код: java 1. 2. 3. 4. 5. 6. 7. в РСУБД Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. т.е. конечная цель маппинга - получить или "договориться" с РСУБД на такие таблицы с данными и связями\действиями (как каскад) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 10:13:41 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, ТС хотел чтобы phone не знал об employe, поэтому @ManyToOne не надо, ну и mappedBy соответственно тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 10:38:53 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, ТС хотел чтобы phone не знал об employe, поэтому @ManyToOne не надо, ну и mappedBy соответственно тоже. мне интересен этот вариант. Он жизненнен вообще? Распиши классы и, главное! - SQL DDL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 10:49:51 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, классы: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. DDL: book id (PK) comment id (PK) book_id (FK->book.id) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:15:56 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123Он жизненнен вообще?да, с небольшими поправками ) redhat, например, не рекомендует jpa1, например, такое не рекомендует мир делится в этом смысле на две части - первая не рекомендует, вторая недоумевает, почему первая не рекомендует ps я во второй ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:23:59 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, вот смотри какая штука. Твой вариант, действительно есть в маппинге и жизни (их всего 2). Но, ситуация кардинально меняется отношением к таблице Комментарии (Телефоны). Она из подчинённой, удаляемой по каскаду вместе с сотрудником, стала главной и неудаляемой. А книжка или сотрудник стали справочной таблицей к этой по FK. Это кардинальное различие в двух маппингах и моделях жизненных ситуаций. По ТС я вижу, что телефоны надо удалять, значит каскад, значит IMHO мой вариант выше. ЗЫ. В access субд )))) есть понятие подчинённая таблица с каскадом и справочная с FK. В других СУБД по другому называется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:36:21 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
grasoff.net, я считаю, что РСУБД главнее хибера)) Поэтому я вообще тут отдельно))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:38:04 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
grasoff.net, ну вообще такая связь, когда коммент однозначно имеет смысл только для какой-то одной книги и без нее существовать не может, или аналогично с сотрудниками - телефонами, проще реализуется коллекцией. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:38:08 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, ну тут каскад никто не мешает поставить Код: java 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:40:51 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerкогда коммент однозначно имеет смысл только для какой-то одной книгиэто 1 к 1 и оффтоп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:41:56 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, ну тут каскад никто не мешает поставить Код: java 1. 2. 3. тогда не понял разницы, если DDL твой и мой одинаков. Кстати, проверь - работает каскад? Я про то что есть 2 варианта бизнес-логики и маппинга ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:43:37 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, это 1 к 1 и оффтоп Не один к одному, а один ко многим. Одна книга - много коментов. Но каждый комент имеет смысл только для одной книги, его нельзя присобачить к другой и он не может существовать отдельно от книги. Тогда нужно использовать коллецию элементов и не делать комент самостоятельной сущностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 11:53:27 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, это 1 к 1 и оффтоп Не один к одному, а один ко многим. Одна книга - много коментов. Но каждый комент имеет смысл только для одной книги, его нельзя присобачить к другой и он не может существовать отдельно от книги. Тогда нужно использовать коллецию элементов и не делать комент самостоятельной сущностью. хорошо бы привести DDL но мы утонем в данном случае. Часто для телефона удобнее именно сущность и отдельная таблица. Поэтому IMHO Embedded лучше не рассматривать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 12:03:39 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, мы запутались в терминологии. Щас перефразирую. Если использовать для телефонов коллекцию эмбед элементов, то с точки зрения приложения это все равно сущность - такой же класс как и был. С точки зрения базы - это отдельная таблица, не имеющая в общем случае суррогатного первичного ключа и имеющая фк на сотрудника. То есть хибер не позволит выбрать из базы телефоны и сохранить их туда отдельно. Только вместе с сотрудником, которому они принадлежат. Таким образом, весь жизненный цикл телефона полностью контролирует сотрудник. Удаляем сотрудника - удаляются телефоны. Никаких каскадов руками писать не нужно, никакие другие классы не могут иметь ссылку на телефон. Думаю, что это правильно. Щас поэкскрементирую и выложу результаты каскада и ддл для всего этого добра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 12:36:48 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, ок. Только давай тогда 3 варианта и так как выложил я (классы-dll-пример заполнения БД - хинт таблица для форума) 1. Мой вариант (главная-Сотрудник с каскадом) 2. вариант СПРАВОЧНИК (главная табла -Телефонный справочник без удаления). FK только для целостности и допускаются висящие телефоны без сотрудников. 3. Embedded Это разные варианты именно по бизнесу от БА ______________________________________________ "Сделай настолько просто, насколько это возможно, но не проще". © А. Эйнштейн. AutoPOI.ru — ГИС-технологии для Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 12:49:23 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, что это? хинт таблица для форума ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 12:52:20 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, HTML табличка с примерами данныз в БД для ТС женского пола)) типа такой Заголовок#IDjavapecker ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 13:01:58 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, У меня просто скрин был. Поэтому я привёл скрин. Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 13:05:54 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, вариант СПРАВОЧНИК (главная табла -Телефонный справочник без удаления). FK только для целостности и допускаются висящие телефоны без сотрудников. Я не понимаю зачем так извращен этот вариант. Он от первого ничем не отличается, кроме того, что телефон не знает ничего о сотруднике. Висячие телефоны прекрасно работают и в первом варианте и в этом. Каскад работает как в первом так и во втором варианте. Не понимаю почему вдруг таблица телефонов стала главной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 13:29:21 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, вариант СПРАВОЧНИК (главная табла -Телефонный справочник без удаления). FK только для целостности и допускаются висящие телефоны без сотрудников. Я не понимаю зачем так извращен этот вариант. Он от первого ничем не отличается, кроме того, что телефон не знает ничего о сотруднике. Висячие телефоны прекрасно работают и в первом варианте и в этом. Каскад работает как в первом так и во втором варианте. Не понимаю почему вдруг таблица телефонов стала главной. висячие телефоны в первом варианте НЕ допускаются, т.к. ОНИ НЕ НУЖНЫ БИЗНЕСУ. Это не справочник городов или улиц. Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 13:50:06 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerНе понимаю почему вдруг таблица телефонов стала главной. если в ТЗ вместо Телефона - Адрес, то БА может задать требования и делаем Модель по варианту 2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 13:52:06 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, Я спрашиваю, почему в своем варианте ты называешь главной таблицу сотрудников, а во втором варианте главной - таблицу телефонов? База одинаковая в одном и другом случае. В приложении разница только в том, что в телефоне нет ссылки на сотрудника. В коде который ты выложил нет никаких ограничений, которые запретили бы создавать висячий телефон. В моем варианте их тоже нет, но если сделать так в твоем: Код: java 1. 2. или так в моем: Код: java 1. 2. 3. то ты не сможешь сохранять сиротливые телефоны и там и там. И все. по поводу этого: Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей? См. выше - установи ограничения. Есть они или нет - они одинаково работают для первого и второго варианта. Ну и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника? я нигде не буду пользоваться номером отдельно от сотрудника. И у меня навигация будет всегда от сотрудника к телефону, но не наоборот. Поэтому - второй вариант. И в твоем и в моем варианте связью нужно управлять, эмбед позволяет это делать автоматически без использования каскада. Поэтому еще лучше - третий вариант, потому что он гарантирует, что сиротливых телефонов не будет и они всегда будут синхронизированы с сотрудником. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:11:12 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, не понятно, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Возьми Access и посмотри. Один ко многим: 1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо) 2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные) Будет 2 модели по Бизнесу, а также разный ГУИ! ОК? PS/ Каскад решает очень многое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:31:26 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, давай, сделай примерчики, и завтра поковыряем демки и генерацию схемы хибером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:33:48 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, сделал под нетбинс 7.2+Postgres. В первых двух случаях схема генерится одинаковая. Висячие телефоны сохраняются. С добавлением optional = false или nullable = false не сохраняются. В третьем случае для телефона генерится таблица без первичного ключа с фк на сотрудника. Выложить проекты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:37:16 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerНу и кстати, а нафига мне иметь в телефонном номере ссылку на сотрудника? afaik на rsdn чел мучился именно с каскадом. У него не выходило именно без этой ссылки. Попробуй и выложи минимальный с каскадом для 1-го варианта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:38:31 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, проекты не надо. Лучше как выше написал: 1. Каскад без висячих 2. без каскада + висячие само собой 3. без PK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:40:38 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:40:40 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, почему ты упорно пытаешься всю жизнь свести к одному варианту, одному маппингу и одной модели? Я пытаюсь сделать не это. Я пытаюсь доказать, что за исключением того, что во втором варианте в телефоне нет ссылки на сотрудника, варианты одинаковые. Можно/нельзя удалять, Допускать/Не допускать висячие телефоны настраивается одинаково для обоих вариантов. ок. Давай свой вариант, только проверь каскад и отсутствие висячих (мне именно это надо было) Для сабжа и ТС это будет идеальный вариант. Ведь так? И закроем тему) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:55:11 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, автор1. Сотрудник ---> Заказы для Организации где плевать на заказы (удалять надо) 2. Сотрудник ---> Заказы для Организации с производством Товаров (удалять нельзя, т.к. они Главные) Если у меня фигурирует заказ самостоятельно где-то , например я получаю список заказов , и для каждого заказа хочу посмотреть к какому сотруднику он относится, мне ЕСТЕСТВЕННО ПОНАДОБИТСЯ ССЫЛКА на сотрудника в заказе. Тут вопрос не в том, могут существовать сиротливые заказы или нет и кто главный, и однозначно, в обоих случаях только твой первый вариант. Второй вариант подойдет для случая когда мне не нужно из заказа тянуть сотрудника. Для заказа это маловероятная ситуация, а вот для телефона самое оно. Потому что вполне у меня может быть список сотрудников, я выберу конкретного сотрудника и посмотрю его телефоны. При этом наоборот мне не надо, то есть я не хочу получать список телефонов, открывать телефон и смотреть чей он. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:55:34 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, Для сабжа и ТС это будет идеальный вариант или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 14:58:12 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapeckerPetro123, Для сабжа и ТС это будет идеальный вариант или эмбед, если на телефоны никто кроме сотрудника не будет ссылаться да. Я говорил, что редко бывает, т.к. часто ссылаются и табла разрастается до сущности. Но как пример в 1 проценте случаев - согласен. Тут ТС'ше выбирать ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 15:01:43 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, Тут ТС'ше А с чего ты взял что ТС женского пола? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 15:27:13 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, off ну, если она возмутится, то скажу)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 15:33:48 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, тесты интересные: В первом варианте нужно обязательно перед сохранением установить в коменте книгу, а в книге добавить этот комент, иначе срабатывает ограничение нот нулл на фк. Потом сохраняем книгу - каскадом сохраняется и комент. Хибер делает два инсерта. Во втором варианте книге добавляем комент и сохраняем книгу. Каскадом сохраняется и комент. Хибер делает два инсерта и один апдейт комента. Так что, поведение все-таки не совсем одинаковое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:01:33 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
javapecker, да. много чего разного. Хотя скажу, чисто по БД, то при варианте "Справочник Городов\Адресов\Телефонов - главный" - делается внешний ключик FK и направление связи меняется. т.е. Один город в виде его Id в таблицу-класс Сотрудник. Но это вроде оффтоп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:17:59 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123, согласен, а как определить кто главный если это например сотрудники и автомобили в связи один ко многим? Сотрудник содержит список авто, авто содержит ссылку на сотрудника. По условию одно авто может быть привязано только к одному сотруднику в один момент времени. а у сотрудника может быть сколько хочешь авто одновременно. Авто может вполне быть не занято, сотрудник может не иметь ни одного авто. При удалении сотрудника я не имею права удалять авто, и наоборот. Но, при удалении сотрудника, я обязан почистить ссылки на него у всех его авто. А при удалении авто я обязан удалить его из списка сотрудника, который на нем ездил. По-моему тут равноправие. Вопрос, как чистисть ссылки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:33:28 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
off javapecker, начать от печки, т.к. БА вводит понятие время (твоё - "в один момент времени") Т.е. переход на классику много ко много и промежуточная таблица в виде "Документ-текущийАвтомобиль". Т.е. незанятое авто, у которого просрочен или снята галка в Документе выше. Ссылки чистить процедурами Бизнес-слоя "ЗаключитьКонтракт" \ АннулироватьКонтракт. При аннулировании можешь стереть запись или отправить в архив или (спроси у БА) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2012, 16:50:51 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Petro123Нафига иметь телефонный номер в БД без сотрудника? Т.е. ничей?Да. А почему это так удивляет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2012, 06:34:52 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Так а по существу вопроса? Есть мэппинг двух сущностей Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. То есть я не хочу, чтобы из Comment был доступ к его соотв Book. Поэтому у меня нет в классе Comment - setBook()/getBook(). В данном случае будет же тот же самый результат, как если бы я убрал Код: java 1. 2. из класса Comment. Разве нет? Но просто ж не будет создаваться дополнительная промежуточная таблица. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 00:43:23 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
Сорри, ошибка Правильно Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 00:47:33 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
oson, по существу вам был дан рабочий код. Хибер и маппинг подстраивается под РСУБД, а не наоборот. Поэтому будьте добры включите генерацию БД хибером и протестируйте свой код (классы -- маппинг --DDL --main{}) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 01:35:23 |
|
||
|
Мэппинг для однонаправленной связи
|
|||
|---|---|---|---|
|
#18+
oson, По существу мы чуть не подрались из-за вашего вопроса. А вы опять все перепутали. Давайте по порядку. Ваш вопрос был о том, как лучше замапить книги и коменты так, чтобы коменты о книгах не знали, и доп. таблицу хибер не создал. Рассмотрим ваш вариант из последнего поста. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Еще раз напомню, что значит 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. 2. Если у вас не будет больше в модели никаких сущностей, которые будут ссылаться на коменты (кроме книг), вы можете представить коменты как коллекцию компонентов класса книги. Мапится так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. В таком случае, ответственность за коменты полностью лежит на книге. Нельзя сохранить сиротливый комент, при удалении книги все коменты удаляются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.11.2012, 14:10:10 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2130646]: |
0ms |
get settings: |
11ms |
get forum list: |
29ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
43ms |
get topic data: |
19ms |
get forum data: |
4ms |
get page messages: |
118ms |
get tp. blocked users: |
3ms |
| others: | 285ms |
| total: | 524ms |

| 0 / 0 |
