|
|
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток ... Собственно, вопрос такой - может ли объект объявленный как Embedded учавствовать в отношениях ? То есть хочу приблизительно следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Скажите, можно ли вообще что-то подобное сделать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 09:30:39 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
конечно нет @Embedded вставляет свои колонки в "принимающую" таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 10:03:42 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
exppконечно нет @Embedded вставляет свои колонки в "принимающую" таблицу Спасибо, собственно я так и думал ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 10:22:37 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Хочу вернуть тему к жизни, т.к. есть схожий вопрос, а плодить однотипные темы не хочется. Собственно описание проблемной ситуации. Пытаюсь добиться следующего: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Оно даже получается почти. Person в итоге отображается на две таблицы: 1. PersonTable - ну собственно основная таблица сущности 2. PersonTable_Address - таблица коллекции из свойства adress класса Person. Как и положено с двумя колонками, одна - внешний ключ на запись из основной таблицы сущности, вторая - для хранения данных свойства city класса Address. Единственная проблема, так это то, что провайдер не создает внешнего ключа для поля city в таблице PersonTable_Address. Собственно вопрос: можно ли добиться того, чтобы этот внешний ключ для поля city в таблице PersonTable_Address создавался? По идее имеем: 1. @Embeddable допускает использование для типо значение своих свойств не только примитивы, что явно указано в документации javaee ну и вобщем-то оно работает если использовать через @Embedded. 2. @ElementCollection позволяет использовать embeddable классы. Это тоже явно указано в документации и работает. 3. Ну собственно я ожидал, что embeddable классы при использовании в @ElementCollection будут позволять хранить не только примитивные типы данных, но добиться этого так и не удалось. Есть серьезное подозрение, что это невозможно, но может кому-то удавалось сделать что-то подобное. Возможно такая функциональность реализована не всеми persistence providers. Я использовал EclipseLink. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 17:09:22 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Собственно на возможность решения поставленной задачи намекает вот этот кусок javadoc по поводу аннотации @CollectionTable, которая как указано Specifies the table that is used for the mapping of collections of basic or embeddable types : @CollectionTableIf the embeddable class contains references to other entities, the default values for the columns corresponding to those references may be overridden by means of the AssociationOverride and/or AssociationOverrides annotations. Но пока что манипуляции с @AssociationOverride желаемого результата не принесли... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 17:28:42 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cyst, какой смысл плодить классы и объекты из простых характеристик объекта? Персона: - класс рост - класс Пол - класс адресс - класс город? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 18:25:20 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cyst, Единственная проблема, так это то, что провайдер не создает внешнего ключа для поля city в таблице PersonTable_Address. Создайте сами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 18:41:12 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Petro123, Честно говоря не очень понял вопроса... Но попробую ответить на сколько уловил суть. В данном примере подразумевается, что адрес это некая совокупность характеристик, причем не примитивных типов. Т.е. адрес состоит из ссылки на запись таблицы городов и т.п. (это могут быть и ссылки на запись таблицы стран, запись таблицы улиц, например, но для краткости в примере только город). Есть сущность Person. У неё может быть несколько адресов. Причем редактировать их состав независимо от данной сущности нельзя (предположим должны делаться какие-то проверки сущностью Person). Для решения данной задачи используем embeddeble класс, который позволяет нам указать какие-то характеристики orm, а потом использовать его в разных сущностях как их часть. Пример этот не из реального проекта и даже не из учебного, а взят просто как что-то максимально простое и понятное всем - все персоны и у всех может быть по несколько адресов )). Поэтому особого смысла обсуждать вопрос, например, о том как лучше хранить город - строкой или ссылкой на запись отдельной таблицы смысла нет. Суть проблемы, что вроде как из документации следует, что подобный дизайн возможен, но использовать его на практике не удается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 19:12:21 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
javapecker, Думал об этом, но честно говоря не пробовал. Ну просто по тому, что скорее всего его отсутствие связано с какой-то ошибкой в использовании аннотаций или вообще отсутствием требований в спецификации по поддержке подобного поведения провайдера. И даже если в каком-то одном случае это прокатит, то не факт что этот же трюк прокатит с другим провайдером или другой субд... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 19:16:07 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cystДумал об этом, но честно говоря не пробовал. Ну просто по тому, что скорее всего его отсутствие связано с какой-то ошибкой в использовании аннотаций или вообще отсутствием требований в спецификации по поддержке подобного поведения провайдера. И даже если в каком-то одном случае это прокатит, то не факт что этот же трюк прокатит с другим провайдером или другой субд... Проблема только в генерации таблиц по маппингу? JPA, разве, гарантирует такую функциональность? Это исключительно функциональность отдельно взятого провайдера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 19:20:50 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Проблема в том, что не удается использовать embeddable класс свойства которого должны содержать ссылки на другие сущности в качестве элемента коллекции некой родительской сущности (в данном примере embeddable класс - Address, родительская сущность - Person). То что таблица не так генерируется это как симптом, что мол нет даже внешнего ключа, где он вроде как должен быть. Гарантирует ли JPA, что приведенный способ должен работать х.з. Из приведенной цитаты вроде как следует что да, но возможно на практике поддержка этой функциональности действительно зависит исключительно от провайдера. Но вообще в нете я никаких примеров или однозначных указаний на это не нагуглил. Только вот эту тему нашел по смежному вопросу, где и решил отписаться. Вдруг кто сталкивался и знает ответ. Да и вопрос-то больше имеет теоретическое значение. Так-то понятно, что задачу можно решить и другими способами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 19:42:46 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cystЕсть сущность Person. У неё может быть несколько адресов. Причем редактировать их состав независимо от данной сущности нельзя (предположим должны делаться какие-то проверки сущностью Person). это не имеет смысла. Если Адрес - отдельная сущность. То она редактируется независимо от сущности Персона. Например, написано "ЛеннСкая" и надо поправить букву в неправильном регистре. авторВ данном примере подразумевается, что адрес это некая совокупность характеристик, причем не примитивных типов. Т.е. адрес состоит из ссылки на запись таблицы городов и т.п. (это могут быть и ссылки на запись таблицы стран, запись таблицы улиц, например, но для краткости в примере только город). Разберись ПО Бизнесу! В простейшем случае - адрес - это одна строка. Другое дело, у тебя справочник городов. Тогда это уже не Embeddable Правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 19:50:13 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cyst, не путайте в кучу генерацию таблиц и CRUD. Если не работает CRUD для вашего маппинга, то опишите в чем именно проблема. То что провайдер не создаёт FK колонку или констрейнт к JPA никакого отношения не имеет и никакими "симптомом" не является. Возможно сгенерить таблицы по маппингу применяется исключительно для чернового прототипизирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 19:52:18 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cystПытаюсь добиться следующего: авторвот наиболее простой пример: отделу кадров нужен отчет по сотрудникам по районам проживания. в БД есть такое поле "район" (а еще поля "улица" "дом" и т.д.) большинство операторов на это забивают, и вводят адрес сразу текстовой строкой в другое поле. причем кто как.., и грамматические ошибки тоже не редкость. ну и чиво мне, парсер писать ? (как ни странно, в БД нет таблицы "справочник районов города") обработка ошибок операторов ______________________________________________ "Сделай настолько просто, насколько это возможно, но не проще". © А. Эйнштейн. AutoPOI.ru — ГИС-технологии для Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 20:00:04 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Вы оказались совершенно правы. В итоге приложение работает правильно, так как я от него и ждал. Рано шум поднял. )) Ну а структура таблиц при этом такая как я и описал. Что конечно немного странно. Поле, которое хранит id города даже не проиндексировано провайдером... Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2012, 23:53:02 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cyst Поле, которое хранит id города даже не проиндексировано провайдером. Провайдер ничего не индексирует. Индексирует база данных. Рекомендую изучить и начать использовать liquibase. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 00:08:34 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Petro123, Petro123Если Адрес - отдельная сущность. То она редактируется независимо от сущности Персона. Мммм.... В данном примере Адрес как раз зависимая сущность. Отдельная сущность Персона. Адрес - зависимая от персоны сущность. Т.е. некий отдельный Адрес взять и записать в БД нельзя. Можно только получить Персону, отредактировать у неё список Адресов и Персону записать. Petro123В простейшем случае - адрес - это одна строка. Другое дело, у тебя справочник городов. Тогда это уже не Embeddable Правильно? Ну город - это сущность. Но Embeddable класс Адрес хранит ссылку на один из городов. А у самого Адреса даже id своего нет. Это просто некоторая совокупность характеристик, некоторые из которых должны быть ссылочного типа. Ну и соответственно у персоны может быть некоторый набор таких вот совокупностей характеристик. Petro123Например, написано "ЛеннСкая" и надо поправить букву в неправильном регистре. Ну я уже вобщем-то написал выше, что предметная область от балды выбрана (хранение адресов) просто для иллюстрации как а) максимально простая б) пересекается с примером из первого сообщения в теме. Поэтому смысла в данной теме обсуждать как правильно в базе хранить адреса нет, есть смысл обсуждать как реализовать описанную выше схему (можно придумать другой пример, не с адресами )) ). Но оно как оказалось все нормально работает. Просто таблицы немного странные провайдер генерирует, что меня ошибочно навело на мысль о том, что подобная схема вообще не заработает. P.S.: спасибо за ссылку на интересное обсуждение )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 00:30:22 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Понятно что провайдер сам ничего не индексирует )) Но на основании классов с аннотациями он генерирует некоторый набор sql выражений, описывающих какие таблицы надо создавать, какие индексы создавать, какие внешние ключи создавать и т.д. и т.п., когда создается новая таблица во всяком случае. Ну а в данном случае было бы логично создать внешний ключ для поля город (но не обязательно конечно). Для поля с id родительской записи персоны создал же внешний ключ, да и для прочих подобных полей со ссылками на те или иные сущности, когда embedable не использовался как элемент коллекции. Про liquibase спасибо за наводку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 00:45:05 |
|
||
|
JPA: @Embedded object with relationship
|
|||
|---|---|---|---|
|
#18+
neural_cyst, ты верно сказал, что Пров должен)) генерировать если он уж "подвязался на это дело". Но, одно дело теория, другое - практика. "Перекуём баги на фичи" (с) ))) Если у тебя FK после создания руками, ключи нормально сохраняются, то ручной метод его создания и есть решения проблемы. Как выше предложили. По поводу ссылки выше, то при использовании отдельного модуля Адресов Кладр есть вариант хранения обычного поля Улица\Микрорайон\Квартира как поля без привязки к КЛАДР классификатору. И уже Id привязки к самому классу КЛАДР. Но ты уточнил, что это оффтоп. Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2012, 10:07:16 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38094261&tid=2130285]: |
0ms |
get settings: |
15ms |
get forum list: |
18ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
41ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 274ms |
| total: | 446ms |

| 0 / 0 |
