Что такое hibernate java
Hibernate для начинающих
Я сталкивался (да и не только я) с проблемой развертывания Hibernate и решил попробовать осветить данную тему. Hibernate — это популярный framework, цель которого связать ООП и реляционную базу данных. Работа с Hibernate сократит время разработки проекта в сравнении с обычным jdbc.
Потом в pom.xml вставляем. Нам понадобятся две зависимости: hibernate-core и mysql-connector, но если вы хотите больше функционала — вы должны подключить больше зависимостей.
Существуют стандартные рекомендации подключать зависимости по отдельности, но я так не делаю.
И щелкаем на Import Changes Enable Auto-Import, автоматически импортируя изменения.
Подключаемся к базе данных, которая развернута на локальном компьютере, выбираем поставщика баз данных MySQL.
Вводим имя базы данных, имя пользователя и пароль. Протестируйте соединение.
Выбираем проект и через framework support просим у хибернейта создать за нас Entity файлы и классы с Getter и Setter.
Выбираем Generate Persistence Mapping через кладку Persistence, выбираем jenerate Persistance Mapping, а в появившемся окне прописываем схему базы данных, выбираем prefix и
sufix к автоматически сгенерированным названиям. Будут сгенерированы названия xml файлов и классов с аннотациями:
Дописываем в hibernate.cfg username и password (звёзды поставил я, а так пишите обычным шрифтом).
Вот и все! Дальше через класс main запускаем проект.
Это моя первая статья. Рассчитываю на здравую критику.
Java Hibernate
Вступление
В сегодняшней IT-индустрии хранение и извлечение данных приложений базируется на объектно-ориентированных языках программирования и реляционных базах данных. Базы данных хранят большой объем информации в одном месте. Наряду с этим, они предоставляют эффективный способ поиска записей, чтобы легко и быстро добраться до нужных данных.
Но при работе с объектами есть одна функция, которую база данных не поддерживает, — это хранение самих объектов, поскольку в ней хранятся только реляционные данные. Данные в виде объектов обеспечивают абстракцию и переносимость.
Существует ли метод, с помощью которого возможно напрямую хранить и извлекать объекты в реляционной базе данных? Ответ — да, такая возможность есть. Название этой техники — ORM.
Объектно-реляционное отображение (Object Relational Mapping, ORM)
ORM устраняет несоответствие между объектной моделью и реляционной базой данных. Само название предполагает отображение объектов в реляционные таблицы. Технология ORM преобразует объекты в реляционные данные и обратно. Возникает вопрос: как это делается?
По сути, имя переменной экземпляра присваивается имени столбца, а его значение формирует строку в реляционной базе данных. Теперь вопрос в том, нужно ли объявлять таблицу в базе данных для хранения объектов. Ответ — нет, ORM сделает это за нас, объявив типы данных для столбцов такими же, как и для переменных экземпляра.
Однако для этого нужно выполнить небольшую настройку и сообщить ORM, как будут отображаться объекты. В Java ORM работает с обычными старыми классами объектов Java (POJO), объекты которых необходимо сопоставить. Эти классы по сути состоят из частных переменных экземпляра, параметризованного конструктора с общедоступными геттерами и сеттерами.
Наряду с параметризованным конструктором класс POJO должен иметь открытый конструктор без аргументов, поскольку он необходим ORM для сериализации. Поскольку параметризованный конструктор присутствует, compile не будет добавлять конструктор аргументов самостоятельно, поэтому придется делать это вручную.
Что такое Hibernate?
Hibernate — это высокопроизводительный инструмент объектно-реляционного сопоставления с открытым исходным кодом для языка программирования Java. Он был выпущен в 2001 году Гэвином Кингом и его коллегами из Cirrus Technologies в качестве альтернативы Entity Beans (объектным бинам) в стиле EJB2.
Этот фреймворк отвечает за решение проблем несоответствия объектно-реляционного импеданса. В Java есть спецификация под названием Java Persistence API (JPA), которая описывает управление объектами в реляционной базе данных. Hibernate — это всего лишь реализация JPA.
Архитектура Hibernate
Обсудим компоненты, из которых состоит Hibernate. Hibernate имеет многоуровневую архитектуру и позволяет работать, даже не зная базовых API, реализующих объектно-реляционное сопоставление. Hibernate находится между Java-приложением и базой данных. Архитектура Hibernate подразделяется на четыре уровня:
На приведенной выше диаграмме показаны все четыре слоя. Поток данных между Java-приложением и базой данных выполняется с использованием постоянного объекта, определенного Hibernate. Уровень инфраструктуры Hibernate состоит из различных объектов, таких как конфигурация, фабрика сеансов, сеанс, транзакция, запрос и критерии. Эти объекты создаются вручную, по мере необходимости.
Объект конфигурации. Первый объект Hibernate, который должен присутствовать в любом Hibernate-приложении. Он активирует платформу Hibernate. Объект конфигурации создается только один раз во время инициализации приложения. Это родительский объект — именно из него создаются все остальные. Он проверяет, является ли файл конфигурации синтаксически правильным или нет. Он предоставляет свойства конфигурации и сопоставления, необходимые Hibernate.
Объект фабрики сеансов. Фабрика сеансов — это массивный потокобезопасный объект, используемый несколькими потоками одновременно. Таким образом, в приложении он должен быть создан только один раз и сохранен для последующего использования. Для каждой базы данных необходим отдельный объект фабрики сеансов. Фабрика сеансов отвечает за настройку Hibernate посредством свойств конфигурации, предоставляемых объектом конфигурации.
Объект сеанса. Облегченный объект, который создается каждый раз, когда нужно взаимодействовать с базой данных. Постоянные объекты сохраняются и извлекаются с помощью объекта сеанса. Это не потокобезопасный объект, поэтому его следует уничтожить после завершения взаимодействия.
Объект транзакции. Представляет собой единицу работы с базой данных. Это необязательный объект, но его следует использовать для обеспечения целостности данных и в случае возникновения какой-либо ошибки — выполнять откат.
Объект запроса. Объект запроса нужен для записи запросов и выполнения операций CRUD в базе данных. Можно написать запрос на SQL или воспользоваться языком запросов Hibernate (HQL). В процессе реализации вам станет известно о HQL больше.
Объект критериев. С его помощью выполняются объектно-ориентированные запросы для извлечения объектов из базы данных.
Как настроить Hybernate?
Во-первых, нужно установить Hibernate у себя в проекте. Можно загрузить jar-файл или воспользоваться более удобным способом, например, применить maven. Так и поступим. Загрузим зависимость hibernate, определенную в POM.xml.
Фреймворк Hibernate должен знать, как сопоставлять объекты, учетные данные сервера базы данных, где будут храниться и откуда будут извлекаться объекты, и еще несколько свойств. Вопрос в том, как передать всю эту информацию в Hibernate.
Эта настройка выполняется с помощью двух XML-файлов.
Рассмотрим пример работы с объектом Flight. В качестве переменных экземпляра он содержит идентификатор (ID), номер рейса, место отправления, место прибытия, дату рейса и тариф. Идентификатор будет первичным ключом таблицы.
Свойство hbm2ddl.auto проверяет или экспортирует язык определения данных схемы при создании объекта фабрики сеансов. Здесь мы прописали операцию обновления, которая обновит базу данных, не затрагивая ранее записанные данные. Недостает еще нескольких, таких как проверка, создание и создание-удаление.
Настало время, когда нужно создать класс POJO для рейсов ( Flights ), объекты которого будут сохраняться в таблице FLIGHTS. Здесь есть также пустой конструктор по умолчанию, необходимость которого мы обосновали ранее.
Один вопрос, который наверняка приходит вам в голову: если мы, Java-разработчики, пользуемся инструментарием Java, зачем выполнять настройку с использованием XML? Есть ли какой-нибудь другой способ? Ответ таков: да, но только частично.
Нужно просто добавить аннотации внутри класса POJO. Отдельного файла не требуется:
Аннотацию необходимо указывать непосредственно над объявлением поля.
Реализация Hibernate
Другой способ будет определен в приведенном ниже примере. Процедура создания всех остальных объектов одинакова для обоих вариантов.
Операция сохранения
Метод сохранения в объекте сеанса выполняет задачу вставки объекта.
Операция обновления
Теперь продвинемся вперед и попробуем обновить уже существующие в таблице данные.
Примечание: если вам хочется вывести объекты, извлеченные из базы данных, на консоль, добавьте метод toString() в класс POJO, иначе выведется хэш-код.
Операция удаления
После выполнения метода deleteFlight таблица становится пустой. В приведенном выше коде мы сначала извлекли объект по его идентификатору и передали его методу удаления. Если все пойдет хорошо, транзакция окажется зафиксирована, в противном случае выполнится откат.
И еще одно: хотим ли мы обновить объект в базе данных или удалить его, нам понадобится значение его первичного ключа. Однако у нас не всегда есть возможность его получить. Кроме того, для этого необходимо выполнять сложные операции с данными. Цели можно достичь с помощью HQL, аналогичного SQL, но он удаляет шаблонный код. Это означает, что теперь не нужно использовать операторы select с запросами.
Все, что мы изучили, также можно повторить, посмотрев это видео.
Что такое hibernate
В этой статье я постараюсь максимально просто объяснить Вам что такое hibernate фреймворк:
Все вышеперечисленное закрепим примером. А для начала постараемся вникнуть в теорию.
Hibernate — это библиотека, которая предназначена для задач объектно-реляционного отображения. Примерно такое описание будет в википедии. Если простыми словами — hibernate позволяет разработчику работать с базой данных не напрямую, как мы это делали с помощью библиотеки JDBC в статье Работа с базой данных, а с помощью представления таблиц баз данных в виде классов java.
Чтобы до конца понять дебри терминов давайте разберем что такое JPA — Java Persistance API.
JPA — спецификация, которая дает возможность сохранять в удобном виде Java-объекты в базе данных. Hibernate — это одна из самых популярных реализаций этой спецификации. Вот такая вот драма. Данные термины даны только в ознакомительных целях так как очень часто запутывают и пугают начинающих разработчиков.
Как это работать с базой данных через классы java? Если Вы открыли эту статью, то наверняка уже подключали базу данных к своему приложению и работали с ней. Если нет — то настоятельно советую прочитать цикл статей Java WEB, в которых подробно описано как создать веб приложение на чистой Java. Также, советую ознакомитья с SQL. А если я прав, и Вы уже знакомы с подключением базы данных, то наверняка работали с ней таким образом: создавали объект, который отображает таблицу базы данных. Например таблицу users с полями:
Потом писали метод подключения к базе, возможно даже пул соединений. Далее был DAO класс в котором делался запрос в базу, доставались или создавались данные, распарсивали их и подавали в виде списка или объекта примерно вот таким образом:
Hibernate дает Вашей разработке приложений новые инструменты: теперь вместо кучи ненужного кода нужно просто создать класс-сущность базы данных, пометить его специальным аннотациями и фреймворк все сделает за Вас.
Это называется ORM — Object Relational Mapping. Вам всего лишь нужно создать классы, которые соответствуют таблицам в базе данных, и написать методы, которые Вы хотите сделать с данными (получить, удалить, создать, обновить). Hibernate сам генерирует SQL запрос и выполняет его. Причем, ему не важно какую базу данных Вы используете. Это дает возможность переключать базы данных и не заботиться о том, что код не будет работать.
С теорией закончили. Теперь давайте узнаем как подключить Hibernate, мапить классы и делать простые запросы.
Начнем с нуля. Создадим простое Maven приложение. Если Вы используете Eclipse: File->New->Maven project.
Не забудьте проставить галочку возле Create a simple project. Даем нашему проекту название:
Далее нужно подключить библиотеку hibernate, JPA и драйвера к базе данных к нашему проекту. В данном примере я использую Postgresql, но разницы не будет никакой если Вы будете использовать другую базу данных. Я укажу место, где нужно будет сделать поправки.
После подключения зависимостей мой файл pom.xml выглядит так:
Теперь нужно придумать с чем будет работать наше приложение. Предлагаю использовать пример, который я описал выше. В этой ознакомительной статье с Hibernate я покажу работу этого фреймворка только с одной таблицей. Создадим в нашей постгрес базу данных hibernate_tutorial и в этой базе создадим таблицу users.
С этим, думаю, проблем не будет.
Теперь создадим класс Users в котором будут поля, геттеры, сеттеры, методы equals, hashCode, toString.
public class Users <
public Integer getId ( ) <
return id ;
>
public String getName ( ) <
return name ;
>
public String getEmail ( ) <
return email ;
>
public String getPassword ( ) <
return password ;
>
@Override
public String toString ( ) <
return «Users [id=» + id + «, name=» + name + «, email=» + email + «, password=» + password + «]» ;
>
Ничего особенного в этом классе нет: это простой объект, который Вы видели много раз. Если Вы когда-нибудь слышали или видели аббревиатуру POJO — Plain Old Java Object то это имелся ввиду именно такой класс. Старый простой объект java. Для того, чтобы этот класс стал сущностью базы данных нужно добавить к нему немного аннотаций.
Перед объявлением класса нужно добавить аннотацию @Entity — которая укажет, что данный класс является сущностью. Это часть спецификации JPA. Далее над классом нужно добавить еще одну аннотацию — @Table. Если Ваш класс совпадает с именем таблицы, то ничего добавлять не нужно. Но, в данной аннотации есть атрибут name в значении которого можно указать имя таблицы в базе данных, которую отображает класс. Поля класса нужно пометить аннотацией @Column в атрибут которой можно также поместить имя поля в таблице базы данных. Отдельного внимания заслуживает поле Id. Для него есть отдельная аннотация @Id. Для генерируемого значение важно указать аннотацию @GeneratedValue в атрибут которой нужно указать стратегию генерируемого значение. JPA поддерживает 3 стратегии генерации ключа. Вам же нужно выбрать стратегию в зависимости от того, как Вы генерируете айди в своей базе данных. Чтобы не усложнять и так запутанную тему мы выберем стратегию GenerationType.IDENTITY которая укажет, что мы генерируем это значение автоматически.
@ Entity
@Table ( name = «users» )
public class Users <
@Id
@GeneratedValue ( strategy = GenerationType. IDENTITY )
private Integer id ;
@Column ( name = «name» )
private String name ;
@Column ( name = «email» )
private String email ;
@Column ( name = «password» )
private String password ;
public Integer getId ( ) <
return id ;
>
public String getName ( ) <
return name ;
>
public String getEmail ( ) <
return email ;
>
public String getPassword ( ) <
return password ;
>
@Override
public String toString ( ) <
return «Users [id=» + id + «, name=» + name + «, email=» + email + «, password=» + password + «]» ;
>
Теперь на подобии коннектора подключений нужно указать настройки hibernate, чтобы библиотека знала с какой базой мы работаем, логин, пароль и тип базы. Создадим класс HibernateUtill и добавим в него немного магии.
import java.util.HashMap ;
import java.util.Map ;
import org.hibernate.SessionFactory ;
import org.hibernate.boot.Metadata ;
import org.hibernate.boot.MetadataSources ;
import org.hibernate.boot.registry.StandardServiceRegistry ;
import org.hibernate.boot.registry.StandardServiceRegistryBuilder ;
import org.hibernate.cfg.Environment ;
public class HibernateUtil <
private static StandardServiceRegistry registry ;
private static SessionFactory sessionFactory ;
registryBuilder. applySettings ( settings ) ;
registry = registryBuilder. build ( ) ;
Это конфигурационный файл, который позволяет настроить hibernate без xml. Я стараюсь не программировать с xml там, где это позволяют новые возможности.
Далее создадим простой класс-сервис по CRUD операциям с сущностью Users.
import javax.persistence.criteria.CriteriaQuery ;
import javax.transaction.Transactional ;
public class UsersCRUD <
В данном примере я не буду использовать язык HQL дабы не усложнять материал. Только уточню, что с помощью данного фреймворка можно работать с базой данных очень большим количеством способов, выбор которых падает на программиста и предметную область.
Теперь осталось протестировать наши методы.
public static void main ( String [ ] args ) <
UsersCRUD usersCRUD = new UsersCRUD ( ) ;
Users users1 = new Users ( ) ;
users1. setName ( «John» ) ;
users1. setEmail ( «connor_john@gmail.com» ) ;
users1. setPassword ( «somepswd123» ) ;
usersCRUD. save ( users1 ) ;
Users users2 = new Users ( ) ;
users2. setName ( «Sara» ) ;
users2. setEmail ( «sarra_mother@gmail.com» ) ;
users2. setPassword ( «qwerty123» ) ;
usersCRUD. save ( users2 ) ;
usersCRUD. delete ( userWithId1 ) ;
Ну и результат запуска приложения:
Надеюсь, Вы поняли что такое hibernate и JPA и какие возможности открывает данный фреймворк для программиста. Это лишь малая часть того, что умеет этот инструмент. Но для ознакомления и первого впечатления должно хватить.
Разбор вопросов и ответов с собеседований на Java-разработчика. Часть 6
Библиотеки и стандарты
52. Что такое Hibernate? В чём разница между JPA и Hibernate?
53. Что такое каскадность? Как она используется в Hibernate?
PERSIST — операции сохранения будут происходить каскадно (для методов save() и persist() ). То есть, если мы сохраняем сущность, связанную с другими сущностями, они также сохраняются в БД (если их ещё там нет)
MERGE — операции обновления будут происходить каскадно (для метода merge() )
REMOVE — операции удаления происходят каскадно (метод remove() )
DETACH — связанные сущности не будут управляться сессией (метод detach() ). То есть, при их изменении не будет автоматического изменения их данных в БД — они переводятся из состояния persistence в detached (сущность, не управляемая JPA)
REFRESH — при каждом обновлении сущности данными из БД ( refresh() — обновляет detached объекты) связанные сущности обновляются так же. Например, вы изменили как-то данные, взятые из БД, и хотите вернуть их изначальные значения. В таком случае вам и пригодится данная операция.
REPLICATE — используется, когда у нас есть более одного источника данных и мы хотим, чтобы данные синхронизировались (метод Hibernate — replicate). У всех сущностей должны быть идентификаторы (id), чтобы не было проблем с их генерацией (чтобы для разных БД одна и та же сущность не имела разных id)
SAVE_UPDATE — каскадное сохранение/удаление (для метода Hibernate — saveOrUpdate )
Если не выбран тип каскадирования, никакая операция с сущностью не будет иметь эффекта для связанных с ней других entity.
54. Может ли Entity класс быть абстрактным?
55. Что такое entity manager? За что отвечает?
56. Что такое класс Assert? Зачем его использовать?
assertTrue( ) — ожидаемое значение, полученное в качестве аргумента, должно быть true
assertFalse( ) — ожидаемое значение, полученное в качестве аргумента, должно быть false
Шпаргалка Java программиста 1: JPA и Hibernate в вопросах и ответах
Знаете ли вы JPA? А Hibernate? А если проверить?
За время работы Java программистом я заметил, что как правило программисты постоянно и планомерно используют от силы 10-20% от возможностей той или иной технологии, при этом остальные возможности быстро забываются и при появлении новых требований, переходе на новую работу или подготовке к техническому интервью приходится перечитывать все документации и спецификации с нуля. Зато наличие краткого конспекта особенностей тех или иных технологий (шпаргалок) позволяет быстро освежить в памяти особенности той или иной технологии.
Данная статья будет полезна и для тех кто только собирается изучать JPA и Hibernate (В этом случае рекомендую сразу открывать ответы), и для тех кто уже хорошо знает JPA и Hibernate (В этом случае статья позволит проверить свои знания и освежить особенности технологий). Особенно статья будет полезна тем кто собирается пройти техническое интервью, где возможно будут задавать вопросы по JPA и Hibernate (или сам собирается провести техническое интервью).
Рекомендую так считать правильные ответы: если вы ответили на вопрос по вашему мнению правильно и полностью — поставьте себе 1 балл, если ответили только частично — 0.5 балл. Везде где только возможно я старался добавлять цитаты из оригинальной документации (но из-за ограничений лицензии Oracle не могу давать слишком большие цитаты из документации).
Общие вопросы
JPA (Java Persistence API) это спецификация Java EE и Java SE, описывающая систему управления сохранением java объектов в таблицы реляционных баз данных в удобном виде. Сама Java не содержит реализации JPA, однако есть существует много реализаций данной спецификации от разных компаний (открытых и нет). Это не единственный способ сохранения java объектов в базы данных (ORM систем), но один из самых популярных в Java мире.
Entity это легковесный хранимый объект бизнес логики (persistent domain object). Основная программная сущность это entity класс, который так же может использовать дополнительные классы, который могут использоваться как вспомогательные классы или для сохранения состояния еntity.
И это тоже допустимо
Может, при этом он сохраняет все свойства Entity, за исключением того что его нельзя непосредственно инициализировать.
1) Entity класс должен быть отмечен аннотацией Entity или описан в XML файле конфигурации JPA,
2) Entity класс должен содержать public или protected конструктор без аргументов (он также может иметь конструкторы с аргументами),
3) Entity класс должен быть классом верхнего уровня (top-level class),
4) Entity класс не может быть enum или интерфейсом,
5) Entity класс не может быть финальным классом (final class),
6) Entity класс не может содержать финальные поля или методы, если они участвуют в маппинге (persistent final methods or persistent final instance variables),
7) Если объект Entity класса будет передаваться по значению как отдельный объект (detached object), например через удаленный интерфейс (through a remote interface), он так же должен реализовывать Serializable интерфейс,
8) Поля Entity класс должны быть напрямую доступны только методам самого Entity класса и не должны быть напрямую доступны другим классам, использующим этот Entity. Такие классы должны обращаться только к методам (getter/setter методам или другим методам бизнес-логики в Entity классе),
9) Enity класс должен содержать первичный ключ, то есть атрибут или группу атрибутов которые уникально определяют запись этого Enity класса в базе данных,
JPA указывает что она может работать как с свойствами классов (property), оформленные в стиле JavaBeans, либо с полями (field), то есть переменными класса (instance variables). Соответственно, при этом тип доступа будет либо property access или field access.
JPA указывает что она может работать как с свойствами классов (property), оформленные в стиле JavaBeans, либо с полями (field), то есть переменными класса (instance variables). Оба типа элементов Entity класса называются атрибутами Entity класса.
Допустимые типы атрибутов у Entity классов:
1. примитивные типы и их обертки Java,
2. строки,
3. любые сериализуемые типы Java (реализующие Serializable интерфейс),
4. enums;
5. entity types;
6. embeddable классы
7. и коллекции типов 1-6
Допустимые типы атрибутов, входящих в первичный ключ:
1. примитивные типы и их обертки Java,
2. строки,
3. BigDecimal и BigInteger,
4. java.util.Date и java.sql.Date,
В случае автогенерируемого первичного ключа (generated primary keys) допустимы
1. только числовые типы,
В случае использования других типов данных в первичном ключе, он может работать только для некоторых баз данных, т.е. становится не переносимым (not portable),
Сложные структуры JPA
Встраиваемый (Embeddable) класс это класс который не используется сам по себе, только как часть одного или нескольких Entity классов. Entity класс могут содержать как одиночные встраиваемые классы, так и коллекции таких классов. Также такие классы могут быть использованы как ключи или значения map. Во время выполнения каждый встраиваемый класс принадлежит только одному объекту Entity класса и не может быть использован для передачи данных между объектами Entity классов (то есть такой класс не является общей структурой данных для разных объектов). В целом, такой класс служит для того чтобы выносить определение общих атрибутов для нескольких Entity, можно считать что JPA просто встраивает в Entity вместо объекта такого класса те атрибуты, которые он содержит.
Может, но только в случае если такой класс не используется как первичный ключ или ключ map’ы.
1. Такие классы должны удовлетворять тем же правилам что Entity классы, за исключением того что они не обязаны содержать первичный ключ и быть отмечены аннотацией Entity (см. вопрос 10),
2. Embeddable класс должен быть отмечен аннотацией Embeddable или описан в XML файле конфигурации JPA,
Существуют следующие четыре типа связей
1. OneToOne (связь один к одному, то есть один объект Entity может связан не больше чем с один объектом другого Entity ),
2. OneToMany (связь один ко многим, один объект Entity может быть связан с целой коллекцией других Entity),
3. ManyToOne (связь многие к одному, обратная связь для OneToMany),
4. ManyToMany (связь многие ко многим)
Каждую из которых можно разделить ещё на два вида:
1. Bidirectional
2. Unidirectional
Bidirectional — ссылка на связь устанавливается у всех Entity, то есть в случае OneToOne A-B в Entity A есть ссылка на Entity B, в Entity B есть ссылка на Entity A, Entity A считается владельцем этой связи (это важно для случаев каскадного удаления данных, тогда при удалении A также будет удалено B, но не наоборот).
Undirectional- ссылка на связь устанавливается только с одной стороны, то есть в случае OneToOne A-B только у Entity A будет ссылка на Entity B, у Entity B ссылки на A не будет.
Mapped Superclass это класс от которого наследуются Entity, он может содержать анотации JPA, однако сам такой класс не является Entity, ему не обязательно выполнять все требования установленные для Entity (например, он может не содержать первичного ключа). Такой класс не может использоваться в операциях EntityManager или Query. Такой класс должен быть отмечен аннотацией MappedSuperclass или соответственно описан в xml файле.
Example: Concrete class as a mapped superclass
В JPA описаны три стратегии наследования мапинга (Inheritance Mapping Strategies), то есть как JPA будет работать с классами-наследниками Entity:
1) одна таблица на всю иерархию наследования (a single table per class hierarchy) — все enity, со всеми наследниками записываются в одну таблицу, для идентификации типа entity определяется специальная колонка “discriminator column”. Например, если есть entity Animals c классами-потомками Cats и Dogs, при такой стратегии все entity записываются в таблицу Animals, но при это имеют дополнительную колонку animalType в которую соответственно пишется значение «cat» или «dog». Минусом является то что в общей таблице, будут созданы все поля уникальные для каждого из классов-потомков, которые будет пусты для всех других классов-потомков. Например, в таблице animals окажется и скорость лазанья по дереву от cats и может ли пес приносить тапки от dogs, которые будут всегда иметь null для dog и cat соотвественно.
2) объединяющая стратегия (joined subclass strategy) — в этой стратегии каждый класс enity сохраняет данные в свою таблицу, но только уникальные колонки (не унаследованные от классов-предков) и первичный ключ, а все унаследованные колонки записываются в таблицы класса-предка, дополнительно устанавливается связь (relationships) между этими таблицами, например в случае классов Animals (см.выше), будут три таблицы animals, cats, dogs, причем в cats будет записана только ключ и скорость лазанья, в dogs — ключ и умеет ли пес приносить палку, а в animals все остальные данные cats и dogs c ссылкой на соответствующие таблицы. Минусом тут являются потери производительности от объединения таблиц (join) для любых операций.
3) одна таблица для каждого класса (table per concrete class strategy) — тут все просто каждый отдельный класс-наследник имеет свою таблицу, т.е. для cats и dogs (см.выше) все данные будут записываться просто в таблицы cats и dogs как если бы они вообще не имели общего суперкласса. Минусом является плохая поддержка полиморфизма (polymorphic relationships) и то что для выборки всех классов иерархии потребуются большое количество отдельных sql запросов или использование UNION запроса.
Для задания стратегии наследования используется аннотация Inheritance (или соответствующие блоки
Java Persistence 2.1. Chapter 2.12, J7EE javadoc
В JPA описаны два типа fetch стратегии:
1) LAZY — данные поля будут загруженны только во время первого доступа к этому полю,
2) EAGER — данные поля будут загруженны немедленно,
Основные операции с Entity
EntityManager это интерфейс, который описывает API для всех основных операций над Enitity, получение данных и других сущностей JPA. По сути главный API для работы с JPA. Основные операции:
1) Для операций над Entity: persist (добавление Entity под управление JPA), merge (обновление), remove (удаления), refresh (обновление данных), detach (удаление из управление JPA), lock (блокирование Enity от изменений в других thread),
2) Получение данных: find (поиск и получение Entity), createQuery, createNamedQuery, createNativeQuery, contains, createNamedStoredProcedureQuery, createStoredProcedureQuery
3) Получение других сущностей JPA: getTransaction, getEntityManagerFactory, getCriteriaBuilder, getMetamodel, getDelegate
4) Работа с EntityGraph: createEntityGraph, getEntityGraph
4) Общие операции над EntityManager или всеми Entities: close, isOpen, getProperties, setProperty, clear
Interface used to interact with the persistence context.
An EntityManager instance is associated with a persistence context. A persistence context is a set of entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed. The EntityManager API is used to create and remove persistent entity instances, to find entities by their primary key, and to query over entities.
The set of entities that can be managed by a given EntityManager instance is defined by a persistence unit. A persistence unit defines the set of all classes that are related or grouped by the application, and which must be colocated in their mapping to a single database.
У Entity объекта существует четыре статуса жизненного цикла: new, managed, detached, или removed. Их описание
1) new — объект создан, но при этом ещё не имеет сгенерированных первичных ключей и пока ещё не сохранен в базе данных,
2) managed — объект создан, управляется JPA, имеет сгенерированные первичные ключи,
3) detached — объект был создан, но не управляется (или больше не управляется) JPA,
4) removed — объект создан, управляется JPA, но будет удален после commit’a транзакции.
An entity instance can be characterized as being new, managed, detached, or removed.
• A new entity instance has no persistent identity, and is not yet associated with a persistence context.
• A managed entity instance is an instance with a persistent identity that is currently associated with a persistence context.
• A detached entity instance is an instance with a persistent identity that is not (or no longer) associated with a persistence context.
• A removed entity instance is an instance with a persistent identity, associated with a persistence context, that will be removed from the database upon transaction commit.
1) Если статус Entity new, то он меняется на managed и объект будет сохранен в базу при commit’е транзакции или в результате flush операций,
2) Если статус уже managed, операция игнорируется, однако зависимые Entity могут поменять статус на managed, если у них есть аннотации каскадных изменений,
3) Если статус removed, то он меняется на managed,
4) Если статус detached, будет выкинут exception сразу или на этапе commit’а транзакции,
1) Если статус Entity new, операция игнорируется, однако зависимые Entity могут поменять статус на removed, если у них есть аннотации каскадных изменений и они имели статус managed,
2) Если статус managed, то статус меняется на removed и запись объект в базе данных будет удалена при commit’е транзакции (так же произойдут операции remove для всех каскадно зависимых объектов),
3) Если статус removed, то операция игнорируется,
4) Если статус detached, будет выкинут exception сразу или на этапе commit’а транзакции,
1) Если статус detached, то либо данные будет скопированы в существующей managed entity с тем же первичным ключом, либо создан новый managed в который скопируются данные,
1) Если статус Entity new, то будет создана новый managed entity, в который будут скопированы данные прошлого объекта,
2) Если статус managed, операция игнорируется, однако операция merge сработает на каскадно зависимые Entity, если их статус не managed,
3) Если статус removed, будет выкинут exception сразу или на этапе commit’а транзакции,
1) Если статус Entity managed, то в результате операции будут востановлены все изменения из базы данных данного Entity, так же произойдет refresh всех каскадно зависимых объектов,
2) Если статус new, removed или detached, будет выкинут exception,
1) Если статус Entity managed или removed, то в результате операции статус Entity (и всех каскадно-зависимых объектов) станет detached.
2) Если статус new или detached, то операция игнорируется,
Аннотации JPA
Она определяет тип доступа (access type) для класса entity, суперкласса, embeddable или отдельных атрибутов, то есть как JPA будет обращаться к атрибутам entity, как к полям класса (FIELD) или как к свойствам класса (PROPERTY), имеющие гетеры (getter) и сетеры (setter).
Для такого перекрывания существует четыре аннотации:
1. AttributeOverride чтобы перекрыть поля, свойства и первичные ключи,
2. AttributeOverrides аналогично можно перекрыть поля, свойства и первичные ключи со множественными значениями,
3. AssociationOverride чтобы перекрывать связи (override entity relationship),
4. AssociationOverrides чтобы перекрывать множественные связи (multiple relationship),
Example 2: Overriding of the mapping for the phoneNumbers relationship defined in the ContactInfo
embeddable class.
The Cacheable annotation specifies whether an entity should be cached if caching is enabled when
the value of the persistence.xml shared-cache-mode element is ENABLE_SELECTIVE or
DISABLE_SELECTIVE. The value of the Cacheable annotation is inherited by subclasses; it can be
overridden by specifying Cacheable on a subclass.
Cacheable(false) means that the entity and its state must not be cached by the provider.
If the shared-cache-mode element is not specified in the persistence.xml file and the
javax.persistence.sharedCache.mode property is not specified when the entity manager
factory for the persistence unit is created, the semantics of the Cacheable annotation are undefined.
Convert и Converts — позволяют указать класс для конвертации Basic аттрибута Entity в другой тип (Converts — позволяют указать несколько классов конвертации). Классы для конвертации должны реализовать интерфейс AttributeConverter и могут быть отмечены (но это не обязательно) аннотацией Converter.
Аннотация EntityListeners позволяет задать класс Listener, который будет содержать методы обработки событий (сallback methods) определенных Entity или Mapped Superclass.
Callback методы служат для вызова при определенных событиях Entity (то есть добавить обработку например удаления Entity методами JPA), могут быть добавлены к entity классу, к mapped superclass, или к callback listener классу, заданному аннотацией EntityListeners (см предыдущий вопрос). Существует семь callback методов (и аннотаций с теми же именами):
1) PrePersist
2) PostPersist
3) PreRemove
4) PostRemove
5) PreUpdate
6) PostUpdate
7) PostLoad
Подробнее, см Javadoc 7ee или спецификация JPA2.1 глава 3.5.2
Для этого служит аннотация OrderBy и OrderColumn
Подробнее, см Javadoc 7ee или спецификация JPA2.1 глава 11.1.42
Для этого служит аннотация Transient
Подробнее, см Javadoc 7ee или спецификация JPA2.1 глава 11.1.52
Сложные вопросы JPA
У JPA есть шесть видов блокировок, перечислим их в порядке увеличения надежности (от самого ненадежного и быстрого, до самого надежного и медленного):
1) NONE — без блокировки
2) OPTIMISTIC (или синоним READ, оставшийся от JPA 1) — оптимистическая блокировка,
3) OPTIMISTIC_FORCE_INCREMENT (или синоним WRITE, оставшийся от JPA 1) — оптимистическая блокировка с принудительным увеличением поля версионности,
4) PESSIMISTIC_READ — пессимистичная блокировка на чтение,
5) PESSIMISTIC_WRITE — пессимистичная блокировка на запись (и чтение),
6) PESSIMISTIC_FORCE_INCREMENT — пессимистичная блокировка на запись (и чтение) с принудительным увеличением поля версионности,
Подробнее, см Javadoc 7ee и описание оптимистичных и пессимистичных блокировок баз данных.
JPA говорит о двух видов кэшей (cache):
1) first-level cache (кэш первого уровня) — кэширует данные одной транзакции,
2) second-level cache (кэш второго уровня) — кэширует данные дольше чем одна транзакция. Провайдер JPA может, но не обязан реализовывать работу с кэшем второго уровня. Такой вид кэша позволяет сэкономить время доступа и улучшить производительность, однако оборотной стороной является возможность получить устаревшие данные.
Подробнее, см JPA 2.1 specification, 3.9 Caching
JPA говорит о пяти значениях shared-cache-mode из persistence.xml, который определяет как будет использоваться second-level cache:
1) ALL — все Entity могут кэшироваться в кеше второго уровня,
2) NONE — кеширование отключено для всех Entity,
3) ENABLE_SELECTIVE — кэширование работает только для тех Entity, у которых установлена аннотация Cacheable(true) или её xml эквивалент, для всех остальных кэширование отключено,
4) DISABLE_SELECTIVE — кэширование работает для всех Entity, за исключением тех у которых установлена аннотация Cacheable(false) или её xml эквивалент
5) UNSPECIFIED — кеширование не определенно, каждый провайдер JPA использует свою значение по умолчанию для кэширования,
Подробнее, см JPA 2.1 specification, 3.9 Caching
Для этого существует EntityGraph API, используется он так: с помощью аннотации NamedEntityGraph для Entity, создаются именованные EntityGraph объекты, которые содержат список атрибутов у которых нужно поменять fetchType на EAGER, а потом данное имя указывается в hits запросов или метода find. В результате fetchType атрибутов Entity меняется, но только для этого запроса. Существует две стандартных property для указания EntityGraph в hit:
1) javax.persistence.fetchgraph — все атрибуты перечисленные в EntityGraph меняют fetchType на EAGER, все остальные на LAZY
2) javax.persistence.loadgraph — все атрибуты перечисленные в EntityGraph меняют fetchType на EAGER, все остальные сохраняют свой fetchType (то есть если у атрибута, не указанного в EntityGraph, fetchType был EAGER, то он и останется EAGER)
С помощью NamedSubgraph можно также изменить fetchType вложенных объектов Entity.
Подробнее, см JPA 2.1 specification, 3.7 EntityGraph
Для работы с кэшем второго уровня (second level cache) в JPA описан Cache интерфейс, содержащий большое количество методов по управлению кэшем второго уровня (second level cache), если он поддерживается провайдером JPA, конечно. Объект данного интерфейса можно получить с помощью метода getCache у EntityManagerFactory.
Подробнее, см JPA 2.1 specification, 7.10 Cache Interface
Для получения такой информации в JPA используется интерфейс Metamodel. Объект этого интерфейса можно получить методом getMetamodel у EntityManagerFactory или EntityManager.
Подробнее, см JPA 2.1 specification, 5 Metamodel API
JPQL (Java Persistence query language) это язык запросов, практически такой же как SQL, однако вместо имен и колонок таблиц базы данных, он использует имена классов Entity и их атрибуты. В качестве параметров запросов так же используются типы данных атрибутов Entity, а не полей баз данных. В отличии от SQL в JPQL есть автоматический полиморфизм (см. следующий вопрос). Также в JPQL используется функции которых нет в SQL: такие как KEY (ключ Map’ы), VALUE (значение Map’ы), TREAT (для приведение суперкласса к его объекту-наследнику, downcasting), ENTRY и т.п.
Подробнее, см JPA 2.1 specification, Chapter 4 Query Language
В отличии от SQL в запросах JPQL есть автоматический полиморфизм, то есть каждый запрос к Entity возвращает не только объекты этого Entity, но так же объекты всех его классов-потомков, независимо от стратегии наследования (например, запрос select * from Animal, вернет не только объекты Animal, но и объекты классов Cat и Dog, которые унаследованы от Animal). Чтобы исключить такое поведение используется функция TYPE в where условии (например select * from Animal a where TYPE(a) IN (Animal, Cat) уже не вернет объекты класса Dog).
Подробнее, см JPA 2.1 specification, Chapter 4 Query Language
Criteria API это тоже язык запросов, аналогичным JPQL (Java Persistence query language), однако запросы основаны на методах и объектах, то есть запросы выглядят так:
Подробнее, см JPA 2.1 specification, Chapter 6 Criteria API
Отличия Hibernate 5.0 от JPA 2.1 или JPA 2.0 от JPA 2.1
1) Конструктор без аргументов не обязан быть public или protected, рекомендуется чтобы он был хотя бы package видимости, однако это только рекомендация, если настройки безопасности Java позволяют доступ к приватным полям, то он может быть приватным,
2) JPA категорически требует не использовать final классы, Hibernate лишь рекомендует не использовать такие классы чтобы он мог создавать прокси для ленивой загрузки, однако позволяет либо выключить прокси Proxy(lazy=false), либо использовать в качестве прокси интерфейс, содержащий все методы маппинга для данного класса (аннотацией Proxy(proxyClass=интерфейс.class) )
В отличии JPA в Hibernate есть уникальная стратегия наследования, которая называется implicit polymorphism.
Hibernate supports the three basic inheritance mapping strategies:
table per class hierarchy
table per subclass
table per concrete class
In addition, Hibernate supports a fourth, slightly different kind of polymorphism:
В спецификации JPA 2.1 появились:
1) Entity Graphs — механизм динамического изменения fetchType для каждого запроса,
2) Converters — механизм определения конвертеров для задания функций конвертации атрибутов Entity в поля базы данных,
3) DDL генерация — автоматическая генерация таблиц, индексов и схем,
4) Stored Procedures — механизм вызова хранимых процедур из JPA,
5) Criteria Update/Delete — механизм вызова bulk updates или deletes, используя Criteria API,
6) Unsynchronized persistence contexts — появление возможности указать SynchronizationType,
7) Новые возможности в JPQL/Criteria API: арифметические подзапросы, generic database functions, join ON clause, функция TREAT,
8) Динамическое создание именованных запросов (named queries)
Подробнее о изменении интерфейсов и API в JPA 2.1:
1) Интерфейс EntityManager получил новые методы createStoredProcedureQuery, isJoinedToTransaction и createQuery(CriteriaUpdate или CriteriaDelete)
2) Абстрактный класс AbstractQuery стал наследоваться от класса CommonAbstractCriteria, появились новые интерфейсы CriteriaUpdate, CriteriaDelete унаследованные CommonAbstractCriteria,
3) PersistenceProvider получил новые функции generateSchema позволяющие генерить схемы,
4) EntityManagerFactory получил методы addNamedQuery, unwrap, addNamedEntityGraph, createEntityManager (с указанием SynchronizationType)
5) Появился новый enum SynchronizationType, Entity Graphs, StoredProcedureQuery и AttributeConverter интерфейсы,