Есть ли способ переопределить идентификатор в подклассе объекта в JPA?

Question

В соответствии с конкретным требованием, например, с использованием абстрактного базового класса (или суперкласса), мне нужно реализовать простую иерархию из двух объектов, одна из которых должна распространять другую, но иметь другой собственный @Id.

Мой googling об этом, кажется, заключает, что это невозможно или только при условии, что я использую отображаемый суперкласс (который запрещен в моем случае из-за определенной политики).

Я не хочу дублировать код объекта с несколькими десятками атрибутов, а затем мутировать дубликат, добавляя/переопределяя атрибуты, чтобы избежать проблем с будущим обслуживанием, но тогда я застрял в ограничениях JPA.

Любая помощь/предложение будут оценены.

Answer 1

Наличие разных типов id для не-абстрактных производных объектов несовместимо с стратегиями наследования JPA.

Что я имею в виду:

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

• как вы определяете ограничения БД для одного наследования таблицы в таком случае?
• и для совместного наследования?

EDIT: JPA не делает различия между стратегиями наследования, когда дело доходит до определения идентификатора. И вы даже не можете быть уверены, что можете использовать TABLE_PER_CLASS с чистой JPA. Практически все провайдеры реализуют его, но он указан как необязательный и, следовательно, наименее переносимая стратегия наследования.

Вопрос остается. Как выглядят ограничения БД, чтобы таблица использовалась недвусмысленно поставщиком непрерывности? Например. Какие столбцы должны содержать первичный ключ на уровне БД?

Если вы не можете сделать родительский объект ни абстрактным, ни встраиваемым, ни использовать один и тот же идентификатор, вам придется обойти это. Как вы это делаете, зависит от того, чего вы хотите достичь, и каких организационных ограничений у вас есть.

Существует несколько возможностей - наименее инвазивным будет композиция, имеющая A как поле в B, эффективно создавая отношение 1-1.

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

tl; dr Нет, это невозможно.