Доброго времени суток!

Хочу вернуть тему к жизни, т.к. есть схожий вопрос, а плодить однотипные темы не хочется.

Собственно описание проблемной ситуации.

Пытаюсь добиться следующего:




Оно даже получается почти.

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.

Собственно на возможность решения поставленной задачи намекает вот этот кусок 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 желаемого результата не принесли...

Petro123,

Честно говоря не очень понял вопроса...
Но попробую ответить на сколько уловил суть.

В данном примере подразумевается, что адрес это некая совокупность характеристик, причем не примитивных типов.
Т.е. адрес состоит из ссылки на запись таблицы городов и т.п. (это могут быть и ссылки на запись таблицы стран, запись таблицы улиц, например, но для краткости в примере только город).

Есть сущность Person. У неё может быть несколько адресов. Причем редактировать их состав независимо от данной сущности нельзя (предположим должны делаться какие-то проверки сущностью Person).
Для решения данной задачи используем embeddeble класс, который позволяет нам указать какие-то характеристики orm, а потом использовать его в разных сущностях как их часть.

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

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

javapecker,

Думал об этом, но честно говоря не пробовал.
Ну просто по тому, что скорее всего его отсутствие связано с какой-то ошибкой в использовании аннотаций или вообще отсутствием требований в спецификации по поддержке подобного поведения провайдера. И даже если в каком-то одном случае это прокатит, то не факт что этот же трюк прокатит с другим провайдером или другой субд...

Blazkowicz,

Проблема в том, что не удается использовать embeddable класс свойства которого должны содержать ссылки на другие сущности в качестве элемента коллекции некой родительской сущности (в данном примере embeddable класс - Address, родительская сущность - Person).
То что таблица не так генерируется это как симптом, что мол нет даже внешнего ключа, где он вроде как должен быть.

Гарантирует ли JPA, что приведенный способ должен работать х.з. Из приведенной цитаты вроде как следует что да, но возможно на практике поддержка этой функциональности действительно зависит исключительно от провайдера.
Но вообще в нете я никаких примеров или однозначных указаний на это не нагуглил. Только вот эту тему нашел по смежному вопросу, где и решил отписаться. Вдруг кто сталкивался и знает ответ. Да и вопрос-то больше имеет теоретическое значение. Так-то понятно, что задачу можно решить и другими способами.

Blazkowicz,

Вы оказались совершенно правы. В итоге приложение работает правильно, так как я от него и ждал. Рано шум поднял. ))
Ну а структура таблиц при этом такая как я и описал. Что конечно немного странно. Поле, которое хранит id города даже не проиндексировано провайдером...

Спасибо!

Petro123,

Petro123Если Адрес - отдельная сущность. То она редактируется независимо от сущности Персона.
Мммм.... В данном примере Адрес как раз зависимая сущность.
Отдельная сущность Персона. Адрес - зависимая от персоны сущность.
Т.е. некий отдельный Адрес взять и записать в БД нельзя.
Можно только получить Персону, отредактировать у неё список Адресов и Персону записать.

Petro123В простейшем случае - адрес - это одна строка.
Другое дело, у тебя справочник городов. Тогда это уже не Embeddable
Правильно?
Ну город - это сущность. Но Embeddable класс Адрес хранит ссылку на один из городов.
А у самого Адреса даже id своего нет. Это просто некоторая совокупность характеристик, некоторые из которых должны быть ссылочного типа. Ну и соответственно у персоны может быть некоторый набор таких вот совокупностей характеристик.

Petro123Например, написано "ЛеннСкая" и надо поправить букву в неправильном регистре.
Ну я уже вобщем-то написал выше, что предметная область от балды выбрана (хранение адресов) просто для иллюстрации как а) максимально простая б) пересекается с примером из первого сообщения в теме.

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

P.S.: спасибо за ссылку на интересное обсуждение ))

Blazkowicz,

Понятно что провайдер сам ничего не индексирует )) Но на основании классов с аннотациями он генерирует некоторый набор sql выражений, описывающих какие таблицы надо создавать, какие индексы создавать, какие внешние ключи создавать и т.д. и т.п., когда создается новая таблица во всяком случае. Ну а в данном случае было бы логично создать внешний ключ для поля город (но не обязательно конечно). Для поля с id родительской записи персоны создал же внешний ключ, да и для прочих подобных полей со ссылками на те или иные сущности, когда embedable не использовался как элемент коллекции.

Про liquibase спасибо за наводку.