Изучаем Java EE 7 - [61]

DESCRIPTION···|VARCHAR··|NULL|NULL|255···|NULL······|510·······|YES
ISBN··········|VARCHAR··|NULL|NULL|255···|NULL······|510·······|YES
NBOFPAGE······|INTEGER··|0···|10··|10····|NULL······|NULL······|YES

Возвращаясь к коду сущности Book (см. листинг 4.7), отмечу, что, поскольку вы использовали аннотацию @GeneratedValue (для автоматического генерирования идентификатора), EclipseLink создал таблицу последовательности для сохранения нумерации (таблица SEQUENCE). В случае со структурой таблицы BOOK JPA придерживался определенных соглашений по умолчанию, присваивая имена таблице и столбцам в соответствии с именем сущности и атрибутов (например, String отображается в VARCHAR(255)).

Проверка сгенерированной схемы

В файле persistence.xml, описанном в листинге 4.10, мы проинформировали EclipseLink о необходимости сгенерировать схему базы данных и сценарии для удаления и создания с помощью следующего свойства:

··········value="drop-and-create"/>

··········value="drop-and-create"/>
По умолчанию поставщик постоянства сгенерирует два SQL-сценария: createDDL.jdbc (листинг 4.13) со всеми SQL-операторами для создания всей базы данных целиком и dropDDL.jdbc (листинг 4.14) для удаления всех таблиц. Это удобно, когда вам необходимо выполнить сценарии с целью создания базы данных в своем процессе непрерывной интеграции.

Листинг 4.13. Сценарий createDDL.jdbc

CREATE TABLE BOOK (ID BIGINT NOT NULL, DESCRIPTION VARCHAR(255), 

···················ILLUSTRATIONS SMALLINT DEFAULT 0, ISBN VARCHAR(255), 

NBOFPAGE INTEGER, PRICE FLOAT, TITLE VARCHAR(255), PRIMARY KEY (ID))
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(15),

······················PRIMARY KEY (SEQ_NAME))
INSERT INTO SEQUENCE (SEQ_NAME, SEQ_COUNT) values ('SEQ_GEN', 0)

Листинг 4.14. Сценарий dropDDL.jdbc

DROP TABLE BOOK
DELETE FROM SEQUENCE WHERE SEQ_NAME = 'SEQ_GEN'

Резюме

В данной главе приведен беглый обзор JPA 2.1. Как и большинство других спецификаций Java EE 7, JPA сосредоточен на простой объектной архитектуре, оставляя позади своего предка — тяжеловесную компонентную модель (также известную как EJB CMP 2.x). В этой главе также рассмотрены сущности, которые представляют собой постоянные объекты, отображающие метаданные с помощью аннотаций или XML.
Благодаря разделу «Все вместе» вы увидели, как следует выполнять JPA-приложения с использованием EclipseLink и Derby. Интеграционное тестирование — важная задача в проектах, а с помощью JPA и баз данных в оперативной памяти вроде Derby сейчас стало очень легко проводить тесты касаемо постоянства.
Из последующих глав вы больше узнаете об основных компонентах JPA. В главе 5 вы увидите, как отображать сущности, связи и наследование в базу данных. А в главе 6 внимание будет сосредоточено на API менеджера сущностей, синтаксисе JPQL. Вы узнаете о том, как использовать запросы и механизмы блокировки, а также будет объяснен жизненный цикл сущностей и то, как добавлять бизнес-логику, когда речь идет о методах сущностей и слушателях.




Глава 5. Объектно-реляционное отображение

В предыдущей главе я подробно рассказал вам об основах объектно-реляционного отображения (Object-Relational Mapping — ORM), которое по сути является отображением сущностей в таблицах и атрибутов в столбцах. Я также поведал вам о конфигурации в порядке исключения, которая позволяет поставщику JPA отображать сущность в таблицу базы данных с использованием всех правил по умолчанию. Однако такие правила не всегда оказываются подходящими, особенно если вы отображаете свою доменную модель в существующую базу данных. JPA сопутствует богатый набор метаданных, благодаря чему вы можете настраивать отображение.
В этой главе я рассмотрю элементарное отображение, а также сконцентрируюсь на более сложных отображениях, таких как отображение связей, композиции и наследования. Доменная модель состоит из объектов, которые взаимодействуют друг с другом. У объектов и баз данных имеются разные способы сохранения информации о связях (ссылок в объектах и внешних ключей в базах данных). Наследование не является чертой, которая от природы имеется у реляционных баз данных, и, следовательно, отображение не столь очевидно. В этой главе я тщательно разберу некоторые подробности и приведу примеры, демонстрирующие то, как следует отображать атрибуты, связи и наследования из доменной модели в базе данных.

Элементарное отображение

Способ, которым Java обрабатывает данные, значительно отличается, если сравнивать его с подходом к обработке информации, используемым реляционными базами данных. В случае с Java мы применяем классы для описания как атрибутов для размещения данных, так и методов для доступа и манипулирования данными. Определив класс, мы можем создать столько его экземпляров, сколько нам потребуется, указав ключевое слово new. В реляционной базе данных информация хранится в структурах (столбцах и строках), не являющихся объектными, а динамическое поведение представляет собой хранимую функциональность вроде триггеров таблиц и хранимых процедур, которые не связаны тесно со структурами данных так, как с объектами. Иногда отображение Java-объектов в основной базе данных может быть легким, при этом могут применяться правила по умолчанию. А иной раз эти правила не отвечают вашим нуждам и приходится настраивать отображение. Аннотации элементарного отображения сосредоточены на настройке требуемой таблицы, первичного ключа и столбцов и позволяют вам модифицировать определенные соглашения об именовании или типизацию (речь может идти о не имеющем значения null столбце, длине и т. д.).