Как наследовать @Entity не mapped классом в Hibernate?

Question

[Vitaliy]

Необходима сущность Field, которую будут наследовать такие классы как SliderField, DateField и т.д., при этом они лишь выполняют функцию обертки и их данные из них уже хранит Field в виде ArrayList

Выглядит это так:

@Entity
class Field{

 public String val1;
// ...

public ArrayList<Data> data;

//...
}

class SliderField extends Field{
 public int min.max;

public void setMin(int m);
// ....
}

И вот в таком случае Hibernate ругается "Unknown entity: com.pkg.app.SliderField", хотя сам SliderField никаким образом не Mapped, а лишь передается в .persist после явного преобразования в Field

Comments

[Владимир Смирнов]

Недостаточно данных в вопросе для точного ответа: описана сторона Object из концепции Object-Relational Mapping, но ничего не сказано про Relational, т.е. не видна структура таблиц БД. SliderField и DateField - это отдельные таблицы?

[Vitaliy]

Владимир Смирнов: если делать их отдельными Entity, но это получится не хорошо со стороны структуры БД, так как сами сущности этих типов равноправны и должны все вместе выводиться списком, а если они будут раскиданы на несколько таблиц, то это будет много JOIN'ов

Answer 1

[Владимир Смирнов]

Если я правильно понимаю, все классы проецируются на одну таблицу. При этом Field содержит проекции тех полей таблицы, которые используются во всех классах, а наследники Field проецируют дополнительно специфические для них поля. В таком случае должна подойти следующая конструкция:

@MappedSuperclass
abstract class Field {
//...
}

@Entity
@Table(name = "FIELDS")
class SliderField extends Field {
//...
}

@Entity
@Table(name = "FIELDS")
class DateField extends Field {
//...
}

Основная Ваша ошибка в том, что аннотацией @Entity должны помечаться конечные классы, а не родительские. Промежуточные родительские классы при этом следует отметить как @MappedSuperclass.

Comments

[Vitaliy]

под разные Entity одно имя таблицы? И как это работает? Куда идут данные из классов SliderField,DateField?

[Владимир Смирнов]

Вам бы желательно перед тем, как делать сложные маппинги, попробовать что-то попроще, чтобы понять как вообще работает JPA. Сущности проецируются на запись в таблице БД в тот момент, когда вы вызываете методы чтения/изменения данных, например, EntityManager.persist. Если сильно упрощать, то в этот момент EntityManager "сканирует" метаданные класса (аннотации) и узнаёт имя таблицы и имя полей, которые требуется сохранить. Т.е., что описано в классе (и его родительских классах), то и будет сохранено. При этом не имеет значения, сколько классов содержат в себе информацию об одной и той же таблице. PS toster.ru - это ресурс вопрос и ответов, а не обучающих материалов.

[Vitaliy]

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

[Vitaliy]

Если в одной таблице для всех сущностей хранятся поля, то это будет много NULL (пустых) полей, что вообще не хорошо

[Владимир Смирнов]

Виталий, Вы писали "если делать их отдельными Entity, но это получится не хорошо со стороны структуры БД", теперь пишете что "в одной таблице ... будет много NULL (пустых) полей". Вы всё же в первую очередь определитесь со структурой таблиц в БД, а уж затем решайте как их правильно замапить. Я ответил на конкретный вопрос о построении маппингов на основе имеющейся информации. Судя по всему, Вам следует задать другой вопрос, о том, как правильнее построить структуру таблиц БД. Насчёт пустых полей - многое зависит от СУБД, например, в Oracle они не занимают места, насчёт других СУБД не смотрел (Гугл в помощь). Если в выбранной Вами СУБД под null место расходуется, то перед вами дилемма: либо тратить больше места, но меньше нагружать БД джойнами, либо наоборот.

[Vitaliy]

Владимир Смирнов: да, именно эти два случая (как отдельные таблицы, так и много-много полей в одной таблице). Это та структура, которая не приемлема, с этим уже определился, и вывод только один - нужна одна таблица Field и дополнительная для дополнительных полей, в этом то вся и соль Hibernate, что он слишком абстрагирует

[Vitaliy]

Да и NULL не сколько важно, что они там занимают, важно что при получении данных из таблицы все равно проводится их проверка

[Владимир Смирнов]

Разделение на множество таблиц может усложнить решение в целом, а также есть вероятность впоследствии получить неприятные побочные эффекты, например, вы не можете 100% защититься от случая, при котором запись в таблице-расширении удаляется, а соответствующая ей запись в базовой таблице остаётся. Получается так называемая осиротевшая запись. К тому же, Вы упоминали о том, что много JOIN-ов нежелательно (поддерживаю это мнение), но как вы соберете данные из пар таблиц без джойнов? Вообще, реляционные СУБД не очень подходят для построения иерархических структур. Я бы порекомендовал сделать всё одной таблицей - так проще и надёжнее, а если накладные расходы на null Вас не беспокоят, то серьёзных минусов вообще не вижу.

[Vitaliy]

Владимир Смирнов: например когда у меня будет 10 разных таблиц с 4 одинаковыми и 3 своими полями.

При одном Entity и дополнительном Embedable будет один JOIN, а вот при выделенном Entity на каждый тип будет беда из 10 JOIN-ов, разве что если это все в одном поле, тогда базе придется пробежаться по 4+3*10=34 полям, большая часть из которых NULL.

Конечно, последний способ лучше, чем второй, но вот попроще реализовать первый не дает Hibernate, так как ему нужен только экземпляр класса Field, а не от него наследуемый. В общем это решается копированием в Field, но сказывается на лишнем вызове метода

То есть сам SliderField в persist не принимает, нужно делать slider.getField()

[Владимир Смирнов]

Виталий Столяров: У Вас какая-то мешанина в голове. Попробуйте просто реализовать так, как в моём ответе, создав одну таблицу на все варианты Field. create table fileds (val1 varchar(10), min int, max int, some_date date, ...). Откуда могут взяться джойны, если таблица одна? Включите трассировку SQL в Hibernate и посмотрите запросы. При выборке SliderField будет select val1, min, max from fileds. При выборке DateField будет select val1, some_date from fileds.

[Vitaliy]

Владимир Смирнов: сколько текста и не по теме. Какая еще мешанина? Я все четко описал. JOIN'ы берутся тогда, когда нужно получить не только записи определенного FieldType (Slider, Date...) , а все записи Field независимо от типа