Добрый день!

Возник вопрос - задача :

требуется организовать мапинг не по id как это сделано по умолчанию ,а по уникальному полю:

в схемах OneToMany и ManyToMany

для примера :

сущность User : имеет уникальный праймари кей id - автоинкрементный для mysql.

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

для идентификации пользователя хочется использовать его уникальный user_Id - который моя система получает из другой системы.

user_id - уникален на несколько в нескольких системах на уровне постоянства.




т.е. телефоны должны мапиться не по id ,а по user_id

так же в таблице телефонов есть уникальных phone_id - для каждого номера, помимо помимо автоинкрементного id.


второй вопрос по связке ManyToMany
в класической схеме из трех таблиц user - user_role - role

где user_role - расшифровочная таблица (класс ассоциация)

у каждого пользователя св системе могут быть разные роли (картеж)

так же у каждой роли по мимо id есть ее уникальный role_id

как описать в бинах анноацию для связи ManyToMany - на по первичному праймари ключу ?

а через уникальные поля user_id и role_id ?

Petro123,

id - int
phone_id это сам номер 79055401234 он уникален

user

id user_id1 91681112132 912123221115 9951113355

role

id role_idrole_name1 10admin2 20user15 30guest

user_role

user_id role_id9168111213 109168111213 209121232211 209951113355 30

Да все верно - нельзя закладываться на авто созданные id - готорые генерит хибер.

а вот номера телефонов , как и номера ролей - они уникальны везде во всех схемах и базах.

Мапить нужно по ним.

user
id user_id1 91681112132 912123221115 9951113355

один ко многим : user - phone

phone

id phone_id user_id111 9168111213212 91212322111513 99511133551714 9951113355

в phone уникальный user.user_id - а не user.id

по user.user_id и мапимся.

Petro123Atum1Да все верно - нельзя закладываться на авто созданные id - готорые генерит хибер.
осталось узнать, как ты получишь ID при вставке нового объекта пользователем.
ВИ
- польз-ль нажал кнопку "Новый юзверь".
- дальше?
ЗЫ. Хибер САМ не генерирует ID

мне приходят уже готовые данные из другой системы . моя система не создает новых юзеров .

так что мне придет :

запись user

9168111213 ; имя; фамилия; отчество;год рождения

все что я могу - это добавить ее в мои таблицы .

пролетевшийХибер ВеликийУ каждой таблицы есть PK, и PK идентифицирует в таблице запись.

У хибера есть еще одна заповедь, на которую меньше обращают внимания: не путать красное с соленым и разделять первичный ключ и бизнес ключ. Есть даже специальная аннотация @NaturalId для бизнес ключей. Это наверное лучше всего для описываемого случая: для внутренней работы использовать первичные/вторичные ключи,а для поиска значения из внешней системы.
А для отношений всегда можно указать, какие поля использовать для связывания: @JoinColumn и @OneToMany(mappedBy=...)+@Column


@NaturalId и @JoinColumn c указанием имен полей в обоих классах - должно сработать.

Просто @JoinColumn - когда я указывал имя колонки и имя реверсивной колонки - у меня почему то не сработало !

Да задача такая - я хочу оставить синтетический ключ и (PK) - id - он будет полезен.

но мапинг вести по другим полям.

MasterZivAtum1сущность User : имеет уникальный праймари кей id - автоинкрементный для mysql.

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

Это утверждение является неверным логическим посылом.
И из него соответственно следует неверный вывод -- твоё желание сделать маппинг не по PK.

В книгах и руководствах по Хиберу ( я думаю я не очень сильно ошибусь, если распространю подход Хибера на весь современный JPA, ведь по сути он и был слизан с Хибера) в самом-самом начале есть глава, в которой написана самая главная заповедь Хиберниста:

Хибер ВеликийУ каждой таблицы есть PK, и PK идентифицирует в таблице запись.


Собственно, всё.

Да такое правило есть и вся идея ORM базируется на этом краеугольном камне - pk - id

но в реальной жизни у вас могут быть разные системы и они должны общаться между собой ...

есть XA транзакции итд итп...

есть репликации - и одно дело когда репликация - полностью повторяет содержимое фактически побайтово ... и совсем другое когда она основана на вставках - insert ...


как вариант я рассматривал возможность описать класс user - c id - как PK уникальным но не автоинкрементным ..


тогда это поле и будет равно внешнему user_id из другой системы ... и при insert будет указан этот id

но может возникнуть ситуация, когда в системе появятся свои пользователи ...

и тогда мне потребуется своя последовательность для генерации UUID для пользователей.

нашел такой пример : по @NaturalId
http://www.concretepage.com/hibernate/naturalid_hibernate_annotation.php