JPA Tutorial — ULTIMATE Guide (PDF Download)

Java Persistence API (JPA) — это независимая от производителя спецификация для отображения объектов Java в таблицы реляционных баз данных. Реализации этой спецификации позволяют разработчикам приложений абстрагироваться от конкретного продукта базы данных, с которым они работают, и позволяют им реализовывать операции CRUD (создание, чтение, обновление и удаление) таким образом, чтобы один и тот же код работал на разных продуктах баз данных. Эти структуры не только обрабатывают код, который взаимодействует с базой данных (код JDBC), но также отображают данные в структуры объектов, используемые приложением.

JPA состоит из трех различных компонентов:

• Entities : в текущих версиях сущности JPA являются простыми старыми объектами Java (POJO). В старых версиях JPA требовалось создавать подклассы сущностей из классов, предоставляемых JPA, но поскольку эти подходы труднее тестировать из-за их жесткой зависимости от платформы, более новые версии JPA не требуют, чтобы сущности делили подклассы какого-либо класса инфраструктуры.
• Object-relational metadata . Разработчик приложения должен обеспечить соответствие между классами Java и их атрибутами таблицам и столбцам базы данных. Это можно сделать либо с помощью выделенных файлов конфигурации, либо в более новой версии платформы, также с помощью аннотаций.
• Java Persistence Query Language (JPQL) : поскольку JPA стремится абстрагироваться от конкретного продукта базы данных, платформа также предоставляет выделенный язык запросов, который можно использовать вместо SQL. Этот дополнительный перевод с JPQL на SQL позволяет реализациям платформы поддерживать различные диалекты базы данных и позволяет разработчику приложения выполнять запросы независимо от базы данных.

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

• maven> = 3.0 в качестве среды сборки
• JPA 2.1, содержащийся в Java Enterprise Edition (JEE) 7.0
• Hibernate как реализация JPA (4.3.8.Final)
• H2 как реляционная база данных в версии 1.3.176

В качестве первого шага мы создадим простой проект maven в командной строке:

Эта команда создаст следующую структуру в файловой системе:

Библиотеки, от которых зависит наша реализация, добавляются в раздел зависимостей файла pom.xml следующим образом:

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

Теперь мы можем приступить к реализации нашей первой функциональности JPA. Давайте начнем с простого класса, который предоставляет метод run() который вызывается в main методе приложения:

Почти все взаимодействие с JPA осуществляется через EntityManager . Чтобы получить экземпляр EntityManager , мы должны создать экземпляр EntityManagerFactory . Обычно нам нужен только один EntityManagerFactory для одного «модуля персистентности» на приложение. Модуль персистентности — это набор классов JPA, который управляется вместе с конфигурацией базы данных в файле с именем persistence.xml :

Этот файл создается в папке src/main/resource/META-INF проекта maven. Как видите, мы определяем один persistence-unit с именем PersistenceUnit который имеет transaction-type RESOURCE_LOCAL . Тип транзакции определяет, как транзакции обрабатываются в приложении.

В нашем примере приложения мы хотим обрабатывать их самостоятельно, поэтому мы указываем здесь RESOURCE_LOCAL . Когда вы используете JEE-контейнер, этот контейнер отвечает за настройку EntityManagerFactory и предоставляет вам только EntityManager . Затем контейнер также обрабатывает начало и конец каждой транзакции. В этом случае вы бы JTA значение JTA .

Устанавливая provider org.hibernate.ejb.HibernatePersistence мы выбираем реализацию JPA, которую мы хотим использовать. Поскольку мы включили Hibernate в качестве провайдера JPA в путь к классу, определив зависимость от него, мы можем ссылаться на реализацию провайдера здесь по имени класса.

Следующим шагом в persistence.xml является информирование поставщика JPA о базе данных, которую мы хотим использовать. Это делается путем указания драйвера JDBC, который должен использовать Hibernate. Поскольку мы хотим использовать базу данных H2 (www.h2database.com), для свойства connection.driver_class установлено значение org.h2.Driver .

Чтобы Hibernate мог создавать подключения к базе данных, мы также должны предоставить URL-адрес подключения. H2 предоставляет возможность создать базу данных в одном файле, путь которого указан в URL JDBC. Следовательно, JDBC URL jdbc:h2:~/jpa указывает H2 создать в домашнем каталоге пользователя файл с именем jpa.h2.db

H2 — это быстрая база данных с открытым исходным кодом, которая может быть легко встроена в приложения Java, так как поставляется в виде одного файла JAR размером около 1,5 МБ. Это делает его подходящим для нашей цели создания простого примера приложения для демонстрации использования JPA. В проектах, которые требуют решений, которые лучше масштабируются для огромных объемов данных, вы, вероятно, выбрали бы другой продукт базы данных, но для небольшого объема данных, которые имеют прочные отношения, H2 — хороший выбор.

Следующее, что мы должны сказать Hibernate — это диалект JDBC, который он должен использовать. Так как Hibernate предоставляет отдельную реализацию диалекта для H2, мы выбираем ее с помощью свойства hibernate.dialect . С помощью этого диалекта Hibernate способен создавать соответствующие операторы SQL для базы данных H2.

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

Второй вариант — hibernate.show_sql который указывает Hibernate печатать каждый оператор SQL, который он выдает в базу данных в командной строке. С этой опцией мы можем легко отследить все операторы и посмотреть, все ли работает как положено. И наконец, мы говорим Hibernate довольно печатать SQL для лучшей читабельности, устанавливая свойство hibernate.format_sql в true .

Теперь, когда мы настроили файл persistence.xml , мы возвращаемся к нашему Java-коду выше:

После получения экземпляра EntityManagerFactory и от него экземпляра EntityManager мы можем использовать их в методе persistPerson для сохранения некоторых данных в базе данных. Обратите внимание, что после того, как мы выполнили нашу работу, мы должны закрыть как EntityManager так и EntityManagerFactory .

EntityManager представляет постоянный модуль, и поэтому нам потребуется в приложениях RESOURCE_LOCAL только один экземпляр EntityManager . Постоянный блок — это кэш для сущностей, которые представляют части состояния, хранящиеся в базе данных, а также соединение с базой данных. Поэтому, чтобы сохранить данные в базе данных, мы должны передать их в EntityManager и вместе с тем в основной кеш. Если вы хотите создать новую строку в базе данных, это делается путем вызова метода persist() в EntityManager как показано в следующем коде:

Но прежде чем мы сможем вызвать функцию persist() нам нужно открыть новую транзакцию, вызвав transaction.begin() для нового объекта транзакции, который мы получили из EntityManager . Если мы пропустим этот вызов, Hibernate выдаст IllegalStateException которое сообщает нам, что мы забыли запустить persist() внутри транзакции:

После вызова persist() мы должны зафиксировать транзакцию, т.е. отправить данные в базу данных и сохранить их там. В случае возникновения исключения в блоке try, мы должны откатить транзакцию, которую мы начали ранее. Но так как мы можем только откатить активные транзакции, мы должны прежде проверить, выполняется ли текущая транзакция, так как может случиться так, что исключение выдается в вызове transaction.begin() .

Класс Person отображается в таблицу базы данных T_PERSON путем добавления аннотации @Entity :

Дополнительная аннотация @Table является необязательной, но вы можете использовать ее для указания конкретного имени таблицы. В нашем примере мы хотим, чтобы все таблицы имели префикс T_, поэтому мы говорим Hibernate создать таблицу T_PERSON . Таблица T_PERSON имеет три столбца: ID , FIRST_NAME , LAST_NAME .

Эта информация предоставляется поставщику JPA с аннотациями @Column и name их атрибута. Даже эта аннотация не является обязательной. JPA будет использовать все свойства класса Java, которые имеют метод setter и getter, и создаст для них столбцы, если вы не исключите их, @Transient их @Transient . С другой стороны, вы можете указать больше информации для каждого столбца, используя другие атрибуты, которые @Column аннотация @Column :

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

Две аннотации @Id и @GeneratedValue сообщают JPA, что это значение является первичным ключом для этой таблицы и что оно должно генерироваться автоматически.

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

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

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

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

Когда мы запустим приведенный выше код, Hibernate выдаст следующие запросы к нашей локальной базе данных H2:

Как мы видим, Hibernate сначала удаляет таблицу T_PERSON если она существует, и создает ее заново. If создает таблицу с двумя столбцами типа varchar(255) ( FIRST_NAME , LAST_NAME ) и одним столбцом с именем id типа bigint . Последний столбец определяется как первичный ключ, и его значения автоматически генерируются базой данных, когда мы вставляем новое значение.

Мы можем проверить, что все правильно, используя Shell, поставляемый с H2. Чтобы использовать эту оболочку, нам просто нужен jar-архив h2-1.3.176.jar :

Приведенный выше результат запроса показывает, что таблица T_PERSON фактически содержит одну строку с идентификатором 1 и значениями для имени и фамилии.

После завершения настройки и этого простого варианта использования мы переходим к некоторым более сложным вариантам использования. Давайте предположим, что мы хотим хранить рядом с людьми также информацию о гиках и их любимом языке программирования. Поскольку гики также являются личностями, мы бы смоделировали это в мире Java как отношение подкласса к Person:

Добавление аннотаций @Entity и @Table к классу позволяет Hibernate создать новую таблицу T_GEEK :

Мы видим, что Hibernate создает одну таблицу для обеих сущностей и помещает информацию о том, сохранили ли мы Person или Geek в новый столбец с именем DTYPE . Давайте сохраним некоторых фанатов в нашей базе данных (для лучшей читабельности я пропустил блок, который перехватывает любое исключение и откатывает транзакцию):

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

Как и ожидалось, новый столбец DTYPE определяет, какой тип человека у нас есть. Столбец FAV_PROG_LANG имеет значение null для людей, которые не являются фанатами.

Если вам не нравится имя или тип столбца дискриминатора, вы можете изменить его с помощью соответствующей аннотации. Далее мы хотим, чтобы столбец имел имя PERSON_TYPE и являлся целочисленным столбцом вместо строкового столбца:

Это приводит к следующему результату:

Не в каждой ситуации вы хотите иметь одну таблицу для всех различных типов, которые вы хотите сохранить в своей базе данных. Это особенно актуально, когда разные типы имеют не все общие столбцы. Таким образом, JPA позволяет вам указать, как планировать различные столбцы. Доступны три варианта:

• SINGLE_TABLE : эта стратегия отображает все классы в одну таблицу. Как следствие, в каждой строке есть все столбцы для всех типов, база данных нуждается в дополнительном хранилище для пустых столбцов. С другой стороны, эта стратегия дает преимущество, заключающееся в том, что в запросе никогда не используется соединение, и поэтому оно может быть намного быстрее
• JOINED : эта стратегия создает для каждого типа отдельную таблицу. Поэтому каждая таблица содержит только состояние сопоставленной сущности. Чтобы загрузить один объект, поставщик JPA должен загрузить данные для одного объекта из всех таблиц, в которые отображается объект. Этот подход уменьшает объем памяти, но с другой стороны вводит запросы на соединение, которые могут значительно снизить скорость запросов.
• TABLE_PER_CLASS : Как и стратегия JOINED , эта стратегия создает отдельную таблицу для каждого типа сущности. Но в отличие от стратегии JOINED эти таблицы содержат всю информацию, необходимую для загрузки этой сущности. Следовательно, для загрузки сущностей не нужны никакие запросы соединения, но он вводит в ситуациях, когда конкретному подклассу неизвестны дополнительные запросы SQL для его определения.

Чтобы изменить нашу реализацию на использование стратегии JOINED , все, что нам нужно сделать, это добавить следующую аннотацию в базовый класс:

Теперь Hibernate создает две таблицы для людей и гиков:

Добавив человека и гиков, мы получим следующий результат:

Как и ожидалось, данные распределены по двум таблицам. Базовая таблица T_PERSON содержит все общие атрибуты, тогда как таблица T_GEEK содержит только строки для каждого гика. Каждая строка ссылается на человека по значению ID столбца.

Когда мы выдаем запрос для лиц, в базу данных отправляется следующий SQL:

Мы видим, что запрос соединения необходим для включения данных из таблицы T_GEEK и что Hibernate кодирует информацию, если одна строка является гиком или возвращает целое число (см. Оператор case).

Код Java для выдачи такого запроса выглядит следующим образом:

Прежде всего мы создаем объект Query , вызывая метод createQuery() EntityManager. В предложении запроса может отсутствовать ключевое слово select. Второй параметр помогает параметризовать метод так, чтобы Query тип Person . Выдача запроса выполняется просто путем вызова query.getResultList() . Возвращаемый список является итеративным, поэтому мы можем просто перебирать объекты Person . Если мы хотим знать, есть ли у нас Person или Geek , мы можем просто использовать оператор instanceof Java.

Запуск приведенного выше кода приводит к следующему выводу:

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

• OneToOne : в этом отношении каждая сущность имеет ровно одну ссылку на другую сущность и наоборот.
• OneToMany / ManyToOne : в этом отношении один объект может иметь несколько дочерних объектов, и каждый дочерний объект принадлежит одному родительскому объекту.
• ManyToMany : в этом отношении несколько объектов одного типа могут иметь несколько ссылок на объекты другого типа.
• Embedded : в этом отношении другая сущность хранится в той же таблице, что и родительская сущность (то есть у нас есть две сущности для одной таблицы).
• ElementCollection : это отношение похоже на отношение OneToMany но в отличие от него указанный объект является Embedded объектом. Это позволяет определять отношения OneToMany для простых объектов, которые хранятся в отличие от «нормальных» Embedded отношений в другой таблице.

Давайте начнем с отношения OneToOne , добавив новую сущность IdCard :

Обратите внимание, что мы использовали общий java.util.Date для моделирования даты выпуска удостоверения личности. Мы можем использовать аннотацию @Temporal чтобы сообщить JPA, как мы хотим, чтобы Date была сериализована в базу данных. В зависимости от базового продукта базы данных этот столбец сопоставляется с соответствующим типом даты / времени. Возможные значения для этой аннотации следующие: TIMESTAMP : TIME и DATE .

Мы сообщаем JPA, что у каждого человека есть ровно одна идентификационная карта:

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

Важным фактом является то, что мы можем настроить время загрузки объекта ID-карты. Поэтому мы можем добавить атрибут fetch к аннотации @OneToOne :

Значение FetchType.EAGER является значением по умолчанию и указывает, что каждый раз, когда мы загружаем человека, мы также хотим загрузить удостоверение личности. С другой стороны, мы можем указать, что мы хотим загружать идентификатор только тогда, когда мы фактически получаем к нему доступ, вызывая person.getIdCard() :

Это приводит к следующим операторам SQL при загрузке всех лиц:

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

Другое важное отношение — это отношение @OneToMany . В нашем примере каждый Person должен иметь один или несколько телефонов:

Каждый телефон имеет внутренний идентификатор, а также номер. Кроме того, мы также должны указать отношение к Person с @ManyToOne , так как у нас «много» телефонов для «одного» человека. Аннотация @JoinColumn указывает столбец в таблице T_PHONE котором хранится внешний ключ для этого человека.

С другой стороны отношения мы должны добавить объекты List of Phone к человеку и аннотировать соответствующий метод получения с помощью @OneToMany поскольку у нас есть «один» человек с «многими» телефонами:

Значение атрибута mappedBy сообщает JPA, какой список на другой стороне отношения (здесь Phone.person ) Phone.person эту аннотацию.

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

Поскольку значение для атрибута fetch устанавливается во время компиляции, мы, к сожалению, не можем изменить его во время выполнения. Но если мы знаем, что мы хотим загрузить все телефонные номера в этом случае использования, а в других случаях использования нет, мы можем оставить отношение для загрузки ленивым и добавить предложение left join fetch в наш запрос JPQL, чтобы сообщить провайдеру JPA также загрузить все телефоны в этом конкретном запросе, даже если для отношения установлено значение FetchType.LAZY . Такой запрос может выглядеть следующим образом:

Мы даем Person псевдоним p и сообщаем JPA, чтобы он также выбирал все экземпляры phones , принадлежащих каждому человеку. Это приводит к Hibernate в следующем запросе выбора:

Обратите внимание, что без left ключевого слова (т. join fetch Только join fetch ) Hibernate создаст внутреннее объединение и загрузит только тех людей, у которых фактически есть хотя бы один номер телефона.

Еще одно интересное отношение — @ManyToMany . Поскольку один гик может присоединиться ко многим проектам, а один проект состоит из множества гиков, мы моделируем отношения между Project и Geek как отношения @ManyToMany :

Наш проект имеет внутренний идентификатор, заголовок типа String и список Geeks . Метод @ManyToMany(mappedBy="projects") для атрибута geeks аннотируется @ManyToMany(mappedBy="projects") . Значение атрибута mappedBy сообщает JPA члену класса с другой стороны отношения, к которому относится это отношение, поскольку для гика может быть несколько списков проектов. Класс Geek получает список проектов и:

Для @ManyToMany нам нужна дополнительная таблица. Эта таблица конфигурируется аннотацией @JoinTable которая описывает таблицу, используемую для хранения назначений гика различным проектам. Он имеет имя GEEK_PROJECT и хранит идентификатор гика в столбце GEEK_ID и идентификатор проекта в столбце PROJECT_ID . Указанный столбец с обеих сторон является просто ID как мы назвали внутренний идентификатор в идентификаторе обоих классов.

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

Поскольку отношение @ManyToMany одинаково с обеих сторон, мы могли бы также аннотировать два списка в обоих классах наоборот:

А с другой стороны Geek :

В обоих случаях Hibernate создает новую таблицу T_GEEK_PROJECT с двумя столбцами PROJECT_ID и GEEK_ID :

Код Java для сохранения этих отношений следующий:

В этом примере мы хотим добавить гиков только к нашему «проекту Java», чей любимый язык программирования, конечно, Java. Следовательно, мы добавляем предложение where к нашему запросу select, который ограничивает результирующий набор вундеркиндами с конкретным значением для столбца FAV_PROG_LANG . Поскольку этот столбец сопоставлен с полем favouriteProgrammingLanguage , мы можем напрямую ссылаться на него по имени его поля Java в инструкции JPQL. Динамическое значение для запроса передается в оператор путем вызова setParameter() для соответствующей переменной в запросе JPQL (здесь: fpl ).

Может случиться так, что вы захотите структурировать модель Java более детально, чем модель базы данных. Примером такого варианта использования является класс Java Period который моделирует время между начальной и конечной датой. Эту конструкцию можно повторно использовать в разных сущностях, поскольку вы не хотите копировать два поля класса startDate и endDate для каждой сущности, у которой есть период времени.

Для таких случаев JPA предлагает возможность моделирования встроенных объектов. Эти объекты моделируются как отдельные классы Java с аннотацией @Embeddable :

Этот объект затем может быть включен в наш объект Project :

Поскольку эта сущность встроена, Hibernate создает два столбца START_DATE и END_DATE для таблицы T_PROJECT :

Хотя эти два значения смоделированы в отдельном классе Java, мы можем запросить их как часть проекта:

JPQL-запрос должен ссылаться на внедренный период, чтобы сформулировать условие, которое ограничивает результирующий набор для проектов, которые начались в определенный день:

Это приводит к следующему запросу SQL:

Начиная с версии 2.0 JPA вы даже можете использовать сущности @Embeddable в отношениях один-ко-многим. Это достигается с помощью новых аннотаций @ElementCollection и @CollectionTable как показано в следующем примере для класса Project :

Поскольку Period является сущностью @Embeddable мы не можем просто использовать нормальное отношение @OneToMany .

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

Интересным моментом в этой таблице является отображение типов перечислений. Чтобы продемонстрировать использование перечислений в JPA, давайте добавим enum ProjectType к сущности:

Как видно из приведенного выше фрагмента, аннотация @Enumerated позволяет нам отображать перечисления в столбцы базы данных, определяя, как сопоставлять различные значения со столбцом. Выбор EnumType.ORDINAL означает, что каждая константа перечисления сопоставляется с определенным числом в базе данных. Когда мы устанавливаем наш «Java-проект» на TIME_AND_MATERIAL мы получаем следующий вывод:

В качестве альтернативы мы также можем использовать значение EnumType.STRING . В этом случае столбец имеет тип String и кодирует перечисление, вызывая его метод name() :

Если оба решения не удовлетворяют вашим требованиям, вы можете написать свой собственный конвертер. Это делается путем реализации интерфейса Java AttributeConverterи аннотирования класса с помощью @Converter. Следующий класс, например, преобразует логическое значение в два числовых значения 1и -1:

Этот преобразователь может применяться к нашему, IdCardкогда мы хотим предоставить информацию, если идентификационная карта действительна или не имеет логического значения:

Вставка удостоверения личности с falseатрибутом validприводит к следующему выводу:

До сих пор мы использовали язык запросов постоянства Java (JPQL) для выдачи запросов к базе данных. Альтернативой JPQL является «Критериальный API». Этот API предоставляет чистый API-интерфейс на основе методов Java для создания запроса.

В следующем примере запрашивается база данных для лиц с firstName = 'Homer':

При начале построения запроса критериев, мы должны спросить EntityManagerдля CriteriaBuilderобъекта. Этот строитель может быть использован для создания реального Queryобъекта. Способ сообщить этому запросу, какую таблицу (таблицы) следует запрашивать, вызывая метод from()и передавая сущность, которая сопоставлена ​​с соответствующей таблицей. QueryОбъект также предлагает способ добавления ИНЕКЯ:

Само условие затем создается с помощью CriteriaBuilderи его equal()метод. Более сложные запросы могут быть собраны с использованием соответствующего логического соединения:

В целом CriteriaQueryопределяются следующие пункты и варианты:

• distinct() Указывает, должна ли база данных отфильтровывать повторяющиеся значения.
• from() : Определяет таблицу / сущность, для которой отправляется запрос.
• select(): Определяет selectзапрос.
• multiselect() : Определяет список выборов.
• where(): Определяет whereпредложение запроса.
• orderBy() : Указывает порядок для запроса.
• groupBy() : Определяет группы, которые сформированы по результату.
• having() : Определяет ограничения для групп, которые определены в результате.
• subquery() : Указывает подзапрос, который можно использовать в других запросах.

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

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

• TABLEЭта стратегия позволяет провайдеру JPA создать отдельную таблицу, содержащую по одной строке для каждой сущности. Эта строка содержит рядом с именем объекта также текущее значение для идентификатора. Каждый раз, когда требуется новое значение, строка в таблице обновляется соответствующим образом.
• SEQUENCE: Если база данных предоставляет последовательности, эта стратегия запрашивает уникальные значения из предоставленной последовательности базы данных. Не все продукты баз данных поддерживают последовательности.
• IDENTITYЕсли в базе данных есть столбцы идентификаторов, в этой стратегии используются столбцы такого типа, предоставляемые базовой реализацией базы данных. Не все продукты баз данных поддерживают столбцы идентификаторов.

Чтобы использовать эту TABLEстратегию, мы также должны сообщить провайдеру JPA некоторые подробности о таблице, которую следует использовать для управления последовательностями:

@TableGeneratorАннотацию сказать нашему провайдеру JPA , что таблица должна иметь название T_SEQUENCESи две колонки SEQ_NAMEи SEQ_VALUE. Имя для этой последовательности в таблице должно быть PHONE: