Содержание
При создании современных приложений корпоративного уровня, работа с объектно-ориентированным программным обеспечением и реляционной базой данных может быть обременительной и трудоемкой. Hibernate -- инструмент объектно/реляционного отображения данных (object/relational mapping tool = ORM tool) для Java окружения. Термин объектно/реляционное отображение (object/relational mapping = ORM), относится к технике отображения объектно-ориентированных данных в реляционную модель со схемой данных основанной на SQL.
Hibernate не только заботится об отображении объектов Java классов в таблицы базы данных (и типов данных Java в типы данных SQL), но также обеспечивает механизм запроса и поиска данных, и может значительно сократить время разработки программного продукта, потраченное, в противном случае, на ручную обработку данных в SQL и JDBC.
Целью Hibernate является освобождение разработчика от 95 процентов общих работ, связанных с задачами программирования долгоживущих (persistence) данных. Возможно, Hibernate не является лучшим решением для приложений, централизованных вокруг данных (data-centric applications), которые используют только хранимые процедуры для реализации бизнес логики в базе данных, но является наиболее полезным при использовании объектно-ориентированных моделей предметной области и бизнес логики в основанном на Java промежуточном слое (middle-tier). Тем не менее, Hibernate помогает удалить из приложенпия или инкапсулировать (скрыть), зависящий от поставщика SQL-код и также помогает в решении стандартной задачи преобразования набора данных (result set) из табличного представления в объектный граф.
Если вы только знакомитесь с Hibernate и Object/Relational Mapping или даже с Java, следуйте, пожалуйста, следующим указаниям:
Прочитайте 30-минутный учебный материал с использованием Tomcat Глава 1, Быстрый старт с использованием Tomcat.
Чтобы понять в каких окружениях (environments) может быть использован Hibernate, прочитайте Глава 2, Архитектура.
Просмотрите директорию eg/ в Hibernate дистрибутиве, она содержит самостоятельное приложение. Скопируйте ваш JDBC драйвер в lib/ директорию и отредактируйте src/hibernate.properties, установив правильные значения для вашей базы данных. Из командной строки в дистрибутивной директории введите ant eg (используя Ant), или под Windows, введите build eg.
Используйте эту справочную документацию как первичный источник информации.
Ответы на Часто Задаваемые Вопросы (FAQ), находятся на сайте Hibernate.
Третьесторонние демонстрационные примеры и учебные материалы представлены на сайте Hibernate.
Раздел Hibernate сообщества (Community Area) на сайте Hibernate, является хорошим источником шаблонов проектирования (design patterns) и разнообразных интеграционных решений (Tomcat, JBoss, Spring, Struts, EJB, и т.д.).
Оффлайн версия сайта Hibernate поставляется вместе с Hibernate в doc/ подкаталоге.
В случае возникновения вопросов, воспользуйтесь форумом пользвователей, который расположен на сайте Hibernate. К тому же мы предоставляем систему отслеживание ошибок JIRA, для сообщений об ошибках и запросах на изменения. Если вы заинтересуетесь разработкой Hibernate, подписывайтесь на список рассылки для разработчиков.
Коммерческая разработка, техническая поддержка продукта, обучение Hibernate предоставляются JBoss Inc. (cм. http://www.hibernate.org/SupportTraining/). Hibernate является проектом JBoss Professional Open Source product suite.
Данный учебный материал разъясняет процесс установки Hibernate 2.1 с использованием Apache Tomcat servlet контейнера для web-приложений. Hibernate прекрасно работает в управляемом окружение (managed environment) со всеми основными J2EE серверами приложений, а также и в самостоятельных Java приложениях (standalone Java applications). В данном материале используется база данных PostgreSQL 7.3, поддержка других баз данных настраивается всего-навсего изменением настройки используемого диалекта SQL в Hibernate.
В начале мы должны скопировать все необходимые библиотеки в установленный Tomcat. Мы используем отдельный web-контекст (webapps/quickstart) для данного учебного материала. Таким образом мы должны рассмотреть глобальный путь поиска библиотек (global classpath) TOMCAT/common/lib и путь поиска библиотек в нашем web-контексте (context classpath) webapps/quickstart/WEB-INF/lib (для JAR-файлов), webapps/quickstart/WEB-INF/classes (для классов нашего приложения). Будем ссылаться на оба пути поиска библиотек и классов, как на глобальный, так и на конекстный (global classpath, context classpath), соответсвующие загрузчики классов будут называться глобальный и контекстный загрузчики (global classloader, context classloader).
Теперь скопируем библиотеки в оба пути поиска (classpath):
Скопируйте JDBC драйвер использумой базы данных в global classpath. Это требование продиктовано программным обеспечением 'DBCP пул соединений' (DBCP connection pool), которое поставляется вместе с Tomcat. Hibernate использует JDBC соединения (JDBC connections) для вызова SQL запросов к базе данных, поэтому вы либо должны предоставить настроенный пул JDBC соединений (JDBC connection pool), либо настроить Hibernate для использования одного из напрямую поддерживаемых пулов встроенных в Hibernate (C3P0, Proxool). Для данного материала, скопируйте библиотеку pg73jdbc3.jar (для PostgreSQL 7.3 и JDK 1.4) в global classpath. Если вы хотите использовать какую-нибудь другую базу данных, то просто скопируйте соответсвующий ей JDBC драйвер.
Никогда не копируйте ничего больше в global classpath в Tomcat, иначе вы получите проблемы с использованием различных инструментов, включая Log4j, commons-logging и т.д. Всегда используйте context classpath для каждого web-приложения, т.е. копируйте библиотеки в WEB-INF/lib а ваши классы, настройки и файлы Java-свойств (properties) в WEB-INF/classes. По умолчанию обе эти директории находятся в context classpath и доступны для context classloader'а.
Hibernate упакован как JAR-библиотека. Файл hibernate2.jar должен быть скопирован в context classpath вместе с остальными классами приложения. При работе, Hibernate использует ряд третьесторонних библиотек, которые поставляются вместе с дистрибутивом Hibernate в каталоге lib/; смотри Таблица 1.1, « Третьесторонние библиотеки использумые в Hibernate ». Скопируйте требуемые третьесторонние библиотеки в context classpath web-приложения.
Таблица 1.1. Третьесторонние библиотеки использумые в Hibernate
Библиотека | Описание |
---|---|
dom4j (требуется) | Hibernate использует dom4j для разбора файлов XML-настроек и XML-мэппинга метаданных. |
CGLIB (требуется) | Hibernate использует данную библиотеку генерации кода для расширения классов во время исполнения (в сочетании с Java reflection). |
Commons Collections, Commons Logging (требуется) | Hibernate использует различные вспомогательные библиотеки из проекта Apache Jakarta Commons. |
ODMG4 (требуется) | Hibernate предоставляет опциональный согласованный с ODMG интефейс управления постоянством (ODMG compliant persistence manager interface). Даже если вы не намерены использовать ODMG API, данный интефейс необходим, если вы собираетесь мэпить коллекции. В данном учебном материале мы не будем мэпить коллекции, но, тем не менее, скопировать данный JAR-файл -- хорошая идея. |
EHCache (требуется) | Hibernate может использовать различные кэш провайдеры (cache providers) для кэша второго уровня (second-level cache). EHCache -- кэш провайдер, используемый по умолчанию, если кэш провайдер не был установлен при конфигурации. |
Log4j (опционально) | Hibernate использует Commons Logging API, который, в свою очередь, может использовать Log4j нижележащего механизма логирования. Если Log4j доступен в context classpath (webapps/quickstart/WEB-INF/lib), Common Logging будет использовать Log4j и конфигурационный файл log4j.properties, расположенный в webapps/quickstart/WEB-INF/classes Пример файла настроек для Log4j входит в состав дистрибутива Hibernate. Таким образом, скопируйте log4j.jar и конфигурационный файл src/log4j.properties в context classpath, если вы хотите видеть, что происходит за сценой. |
Требуется или нет? | Взгляните на файл lib/README.txt из дистрибутива Hibernate. Это самый последний (up-to-date) список третьесторонних библиотек, поставляемых с Hibernate. Здесь перечислены все требуемые и опционалные библиотеки. |
Теперь настроим общий для Hibernate и Tomcat пул соединений с базой данных (shared database connection pool). Это означает, что Tomcat предоставляет пул JDBC соединений (pooled JDBC connections) (используя встроенный DBCP пул), Hibernate запрашивает данные соединения через интерфейс JNDI. Tomcat привязывает (binds) пул соединений к JNDI, для этого добавим объявление ресурса (resource declaration) в главный конфигурационный файл Tomcat, TOMCAT/conf/server.xml:
<Context path="/quickstart" docBase="quickstart"> <Resource name="jdbc/quickstart" scope="Shareable" type="javax.sql.DataSource"/> <ResourceParams name="jdbc/quickstart"> <parameter> <name>factory</name> <value>org.apache.commons.dbcp.BasicDataSourceFactory</value> </parameter> <!-- DBCP database connection settings --> <parameter> <name>url</name> <value>jdbc:postgresql://localhost/quickstart</value> </parameter> <parameter> <name>driverClassName</name><value>org.postgresql.Driver</value> </parameter> <parameter> <name>username</name> <value>quickstart</value> </parameter> <parameter> <name>password</name> <value>secret</value> </parameter> <!-- DBCP connection pooling options --> <parameter> <name>maxWait</name> <value>3000</value> </parameter> <parameter> <name>maxIdle</name> <value>100</value> </parameter> <parameter> <name>maxActive</name> <value>10</value> </parameter> </ResourceParams> </Context>
Контекст, сконфигурированный в данном примере, назван quickstart, и размещен в каталоге TOMCAT/webapp/quickstart. Для доступа к любому из сервлетов (servlets), в браузере наберите следующий путь http://localhost:8080/quickstart (добавив имя сервлета, сконфигурированного в вашем web.xml). Теперь вы можете продолжить и создать простой сервлет с пустым методом process().
С данными настройками Tomcat использует DBCP пул соединений и предоставляет объекты JDBC Connection из этого пула через JNDI имя java:comp/env/jdbc/quickstart. Если вы испытываете проблемы с настройкой и работой пула соединений, обратитесь к документации Tomcat. Если вы получили сообщения с исключительной ситуацией от JDBC драйвера (JDBC driver exception messages), попытайтесь сперва настроить пул JDBC соединений без подключения его в Hibernate. Учебный материал "Tomcat & JDBC" доступен в Web.
Следующим шагом настроим Hibernate для использования пула соединений привязанного (bound) через JNDI. Используем настройку Hibernate через XML-файл. Основной способ настройки, через файл Java-свойств (properties), эквивалентен, но не предоставляет дополнительных расширенных опций. Мы будем использовать настройку через XML, потому что обычно она более удобна. Конфигурационный XML-файл должен быть размещен в context classpath (WEB-INF/classes), под именем hibernate.cfg.xml:
<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN" "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"> <hibernate-configuration> <session-factory> <property name="connection.datasource">java:comp/env/jdbc/quickstart</property> <property name="show_sql">false</property> <property name="dialect">net.sf.hibernate.dialect.PostgreSQLDialect</property> <!-- Mapping files --> <mapping resource="Cat.hbm.xml"/> </session-factory> </hibernate-configuration>
Мы отключили логирование SQL команд, настроили используемый диалект SQL и указали, как Hibernate должен получать JDBC соединения (объявив JNDI имя, к которому Tomcat привязал пул соединений). Диалект (dialect) является обязательным конфигурационным параметром, базы данных отличаются своей интерпретацией SQL "стандарта" (интерпретируют его по своему). Hibernate берет заботу об этих отличиях на себя и поставляется с диалектами для всех основных коммерческих баз данных и баз данных с открытым исходным кодом.
SessionFactory -- это концепция единого хранилища данных (single datastore). При создании нескольких конфигурационных XML-файлов будут использоваться несколько баз данных, и будут созданы несколько объектов (по одному для каждой базы данных) Configuration и SessionFactory.
Самый последний элемент в hibernate.cfg.xml, объявляет Cat.hbm.xml как имя файла XML-мэппинга для долгоживущего класса (persistent class) Cat. Данный файл содержит метаданные, описывающие для Hibernate, как следует сохранить данные из POJO класса (POJO class) в таблицу базы данных (или в несколько таблиц). Вскоре мы вернемся к этому файлу. Сначала давайте создадим POJO класс, а затем объявим метаданные в файле мэппинга (mapping metadata) для созданного POJO класса.
От английского слова "mapping" -- "нанесение на карту; вычерчивание карт; картография; топографическая съемка". В данном контексте означает процесс преобразования/отображения объектной модели данных (POJO) в реляционную (relational) модель и, наоборот, преобразование реляционной модели в объектную по единым правилам, описанным в файле XML-мэппинга (XML mapping file). Другими словами, термин мэппинг означает преобразование Java объектов в строки таблиц базы данных.
Наилучшая для Hibernate модель данных долгоживущих классов -- это Plain Old Java Objects (POJOs, иногда также называемая Plain Ordinary Java Objects). POJO очень похож на JavaBean со свойствами (properties), доступными через getter- и setter-методы, которые прячут внутреннее представление класса от публичного доступа:
package net.sf.hibernate.examples.quickstart; public class Cat { private String id; private String name; private char sex; private float weight; public Cat() { } public String getId() { return id; } private void setId(String id) { this.id = id; } public String getName() { return name; } public void setName(String name) { this.name = name; } public char getSex() { return sex; } public void setSex(char sex) { this.sex = sex; } public float getWeight() { return weight; } public void setWeight(float weight) { this.weight = weight; } }
Hibernate не ограничен использованием каких-то определенных типов, все Java типы и примитивы (такие как String, char и Date) могут быть использованы при мэппинге, включая классы из Java Collections Framework. Их можно использовать в мэппиге как значения (values), коллекции значений (collections of values) или ассоциации (associations) к другим сущностям (entities). Специальное свойство (property) id представляет идентификатор из базы данных (primary key) данного класса, данное свойство настоятельно рекомендовано для использования с сущностями такими как Cat. Hibernate мог бы использовать идентификаторы только для своих внутренних нужд, но скрывая их, мы бы потеряли часть гибкости в архитектуре нашего приложения.
Мы не должны реализовывать никаких специальных интерфейсов для долгоживущих классов (persistent classes), также не должны наследовать наши долгоживущие классы от специального базового класса. К тому же, Hibernate не использует никаких дополнительных обработок исходного кода и байт-кода приложения во время сборки, он полность полагается на рефлексию (reflection) и расширение классов во время исполнения (runtime class enhancement), используя библиотеку CGLIB. Таким образом, не имея никаких зависимостей от Hibernate в нашем POJO классе, мы можем отобразить/замэпить наш класс на таблицу базы данных.
Файл мэппинга Cat.hbm.xml, содержит метеданные необходимые для отображения/мэппинга объектной структуры данных в реляционную структуру (object/relational mapping). Метаданные содержат объявления долгоживущих классов и отображение/мэппинг свойств классов на колонки и внешние ключи таблиц базы данных.
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <hibernate-mapping> <class name="net.sf.hibernate.examples.quickstart.Cat" table="CAT"> <!-- A 32 hex character is our surrogate key. It's automatically generated by Hibernate with the UUID pattern. --> <id name="id" type="string" unsaved-value="null" > <column name="CAT_ID" sql-type="char(32)" not-null="true"/> <generator class="uuid.hex"/> </id> <!-- A cat has to have a name, but it shouldn' be too long. --> <property name="name"> <column name="NAME" length="16" not-null="true"/> </property> <property name="sex"/> <property name="weight"/> </class> </hibernate-mapping>
Каждый долгоживущий (persistent) класс должен иметь идентификатор (на самом деле, только классы представляющие сущности (entities); зависимые объекты, замэпленные как компоненты (components) могут не иметь идентификатора). Идентификтор используется для того чтобы различать долгоживущие объекты: два кота идентичны если выражение catA.getId().equals(catB.getId()) является истинным, данная концепция называется идентичность средствами базы данных (database identity). Hibernate поставляется с несколькими генераторами идентификторов для различных сценариев использования (включая родные (native) генераторы, генераторы для использования database sequence, hi/lo идентификационных таблиц и генераторы для использования идентификторов присвоенных приложением). В данном примере, мы используем UUID-генератор (рекомендован только для тестовых целей, целочисленный суррогатный ключ, сгенерированный базой данных, является наиболее предпочтительным). Также указываем колонку CAT_ID таблицы CAT, для использования под сгенерированный идентификатор (данная колонка используется как первичный ключ таблицы).
Все свойства класса Cat замэплены/отображаются в одну таблицу. Свойство name мы замэпили с использованием явного указания имени колоки таблицы базы данных. Данная техника особенно важна при схеме данных (SQL DDL выражения), автоматически сгенерированной из мэппингов Hibernate с ипользованием инструмента SchemaExport. Все остальные свойства замэплены используя настройки Hibernate по умолчания, это то, что в основном вам и надо. Таблица CAT в базе данных выглядит как:
Колонка | Тип | Модификатор ---------+-----------------------+------------ cat_id | character(32) | not null name | character varying(16) | not null sex | character(1) | weight | real | Indexes: cat_pkey primary key btree (cat_id)
Теперь вы должны вручную создать эту таблицу в базе данных, позже прочитайте Глава 15, Toolset Guide, если желаете автоматизировать данный процесс с использованием инструмента SchemaExport. Данный инструмент умеет создавать полный SQL DDL скрипт, включая опредение таблиц, установка ограничений на типы (???) (custom column type constraints), установка ограничений уникальности (unique constraints) и установка индексов.
Теперь мы готовы стартовать Hibernate Session. Session -- это интерфейс управления постоянством объектов (persistence manager), он используется для сохранения в базу данных и восстановления из нее объектов класса Cat. Но с начала мы должны получить экземпляр класса Session из SessionFactory, Session в Hibernate является единицей-работы (unit-of-work):
SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();
Один экземпляр SessionFactory ответсвеннен за одну базу данных и может использовать только один конфигурационный XML-файл (hibernate.cfg.xml). До того как вы создали экземпляр SessionFactory, вы можете установить другие свойства (и даже изменить метаданные мэппинга) путем доступа к Configuration. Т.к. SessionFactory является неизменяемым (immutable), устанавливать дополнительные свойства и менять метаданные через Configuration можно только до создания экземляра SessionFactory. Где мы создадим экземпляр SessionFactory и каким образом мы будем получать к нему доступ из на шего приложения?
Обычно экземпляр SessionFactory создается только один раз, например при старте приложения, с использованием load-on-startup сервлета (Java Servlet). Это также означает что вы не должны хранить его в переменной-члене вашего сервлета, для этого должно использоваться более подходящее место. Для того чтобы мы могли легко получать доступ к экземляру SessionFactory, нам необходим своего рода Singleton. Подход демонстрируемый далее, решает обе проблемы: конфигурация и легкий удобный доступ к SessionFactory.
Реализуем вспомогательный класс HibernateUtil:
import net.sf.hibernate.*; import net.sf.hibernate.cfg.*; public class HibernateUtil { private static final SessionFactory sessionFactory; static { try { // Create the SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory(); } catch (HibernateException ex) { throw new RuntimeException("Configuration problem: " + ex.getMessage(), ex); } } public static final ThreadLocal session = new ThreadLocal(); public static Session currentSession() throws HibernateException { Session s = (Session) session.get(); // Open a new Session, if this Thread has none yet if (s == null) { s = sessionFactory.openSession(); session.set(s); } return s; } public static void closeSession() throws HibernateException { Session s = (Session) session.get(); session.set(null); if (s != null) s.close(); } }
Данный класс не только заботится о SessionFactory, используя статический член класса, но также имеет ThreadLocal член, для хранения Session текущего выполняемого потока. Перед тем как начать использовать данный вспомогательный класс, удостоверьтесь, что вы понимаете Java-концепцию thread-local переменных.
SessionFactory является потоко-безопасным классом (threadsafe class), несколько потоков могут иметь одновременный доступ к одному экземляру и запрашивать сессии (экземпляры Session). Экземляр класса Session, не является потоко-безопасным (non-threadsafe), он предсавляет отдельную единицу-работы (single unit-of-work) с базой данных. Сессии открываются экземляром класса SessionFactory и закрываются когда вся работа с базой данных завершена:
Session session = HibernateUtil.currentSession(); Transaction tx= session.beginTransaction(); Cat princess = new Cat(); princess.setName("Princess"); princess.setSex('F'); princess.setWeight(7.4f); session.save(princess); tx.commit(); HibernateUtil.closeSession();
В сессии, все операции происходят внутри транзакции, транзакция изолирует операции с базой данных (даже операции только на чтение) от параллельных операций производимых из других транзакций. Мы используем Hibernates Transaction API для абстрагирования от нежележащей транзакционной стратегии, в нашем влучае от JDBC транзакций. Это позволяет помещать наш код в окружение с транзакциями управляемыми контейнером (container-managed transactions, JTA) без каких-либо изменений. Пожалуйста обратите внимание, что пример сверху не обрабатывает исключительные ситуации.
Также обратите внимание, что вы можете вызывать HibernateUtil.currentSession(); столько раз сколько хотите, вы всегда получите текущую сессию для потока в котором работает ваш код. Вы должны удостовериться что сессия закрыта после того как завершена ваша единица-работы (unit-of-work), либо в коде сервлета, либо в фильтре (servlet filter), до того как был послан HTTP отклик (HTTP response). Приятный побочный эффект от закрытия сессии перед самым отправлением HTTP отклика, -- это "ленивая" инициализация POJO объектов: т.к. при генерации представления (HTML), сессия все еще открыта, Hibernate может загружать неинициализированные объекты и инициализировать их по мере обращения к ним.
Hibernate имеет различные способы восстановления объектов из базы данных. Наиболее гибкий -- это использование Hibernate Query Language (HQL). HQL -- это легкий в изучении и мощный объектно-ориентированныый язык, являющийся расширением SQL:
Transaction tx = session.beginTransaction(); Query query = session.createQuery("select c from Cat as c where c.sex = :sex"); query.setCharacter("sex", 'F'); for (Iterator it = query.iterate(); it.hasNext();) { Cat cat = (Cat) it.next(); out.println("Female Cat: " + cat.getName() ); } tx.commit();
Hibernate также предлагает объектно-ориентированный query by criteria API (построение запроса по критерию), данный API использует бесопасные типы для построения запросов. Ну и конечно Hibernate использует объекты PreparedStatement и привязку параметров (parameter binding) для всех SQL-запросов к базе данных. В редких случаях, вы можете использовать низкоуровневые SQL запросы напрямую или получить из Hibernate Session, простой JDBC Connection
В этом небольшом учебном материале, мы только поверхностно коснулись Hibernate. Пожалуйста, обратите внимание, что в наши примеры мы преднамеренно не включили код специфичный для сервлетов. Вы должны создать данный код самостоятельно и вставить вызовы Hibernate в соответсвующих местах.
Помните, что Hibernate, как слой доступа к данным (data access layer), тесно интегрирован в ваше приложение. Обычно все остальные слои зависимы от механизма сохранения объектов (persistence mechanism). Убедитесь что вы абсолютно понимаете этот дизайн.
Высокоуровневое (очень высокоуровневое) представлений архитектуры Hibernate:
Эта схема демонстрирует, что Hibernate использует базу данных (Database) и конфигурационные данные (hiberanate.properties, XML mapping) для предоставления сервисов, делающих объекты долгоживущими (Pesistent Objects), данные сервисы используются приложением (Application).
Нам бы хотелось показать более детальное представление архитектуры времени выполения (runtime architecture). Т.к. Hibernate очень гибкий инструмент и поддерживает несколько вариантов архитектуры времени выполения, мы продемонстрируем два наиболее крайних. "Облегченную" архитектуру имеют приложения предоставляющие Hibernate свои собственные JDBC-соединения и сами управляющие транзакциями. Данный вариант использует минимальное подмножество Hibernate API:
Архитектура "всё в шоколаде" ("full cream") абстрагирует приложение от нижележащих JDBC/JTA API и даёт возможность Hibernate самому заботиться обо всех деталях.
Вот несколько определений объектов изображенных на схемах:
Потокобезопасный, неизменяемый (threadsafe, immutable) кэш откомпилированных мэппингов для одной базы данных. Фабрика для создания объектов класса Session (Hibernate сессий). SessionFactory является клиентом для ConnectionProvider. SessionFactory может поддерживать опциональный кэш для данных, которые используются несколькими транзакциями, этот кэш называют кэш второго уровня (second-level cache) или кэш уровня JVM (JVM-level cache). Данный кэш можно настроить таким образом чтобы он работал как для одного процесса (process-level) так и для нескольких процессов в кластере (cluster-level).
Однопоточный, короткоживущий объект, являющийся посредником между приложением и хранилещем долгоживущих объектов. Обертка вокруг JDBC-соединения. Фабрика для объектов класса Transaction. Содержит обязательный кэш первого уровня (first-level cache) для долгоживущих объектов, используется для навигирования по объектному графу или для поиска объектов по идентификатору.
Долгоживущие Объекты и Коллекции. Однопоточные, короткоживущие объекты содержащие сохраняемое состояние и бизнес функции. Это могут быть обычные JavaBean/POJO объекты, одна их отличительная особенность, это то, что они ассоцированны с одной сессией (Session). Как только их сессия закрыта, эти объекты становятся отсоединенными (detached) и свободными для использования на любом слое/уровне (layer) приложения, например непосредсвенно как объекты передачи данных (data transfer objects) на уровень представления и с него.
Временные Объекты и Коллекции. Экземляры долгоживущих (persistent) классов, которые в данный момент не ассоцированы с сессией (Session). Это могут быть объекты инстанциированые приложением и в данный момент еще не переведенные в долгоживущее (persistent) состояние или они могли быть инстациированы закрытой сессией (TODO как это???).
Транзакция. Опциональный однопоточный, короткоживущий объект, используется приложением для указания атомарной единицы выполняемой работы (atomic unit of work). Абстагирует приложение от нижелещащих JDBC, JTA или CORBA транзакций. В некоторых случаях одна сессия (Session) может породить несколько транзакций.
Поставщик соединений. Опциональная фабрика и пул для JDBC-соединений. Абстрагирует приложение от нижелещащих объектов Datasource или DriverManager. Это внутренний объект Hibernate, он недоступен для приложения, но может быть расширен/реализован разработчиком.
Фабрика транзакций. Опциональная фабрика для экземпляров класса Transaction. Это внутренний объект Hibernate, он недоступен для приложения, но может быть расширен/реализован разработчиком.
В изображенной выше "облегченной" архитектуре, приложение не использует следующих API Hibernate: Transaction/TransactionFactory, ConnectionProvider API и взаимодействует с JTA или JDBC напрямую.
JMX -- это J2EE-стандарт для управления Java-компонентами. Hibernate может быть управляемым посредством стандартного JMX MBean, но т.к. большинство серверов приложений еще не поддерживает JMX, то в Hibernate используются некоторые нестандартные механизмы конфигурации.
Пожалуйста, обратитесь к web-сайту за более детальной информацией о том как настроить Hibernate для работы как JMX-компонент внутри JBoss.
Так как Hibernate разработан для эксплуатации в различных окружениях, существует множество конфигурационных параметров. К счастью, у большинства имеются разумные значения по умолчанию, и Hibernate распространяется с примером настроечного файла hibernate.properties, демострирующим различные опции. Обычно, вам нужно только подредактировать этот файл и положить его в classpath.
Экземпляр класса net.sf.hibernate.cfg.Configuration представляет весь набор мэппингов/отображений типов Java приложения к реляционной базе данных. Экземпляр класса Configuration используется для построения неизменяемой (immutable) SessionFactory. Отображения/мэппинги собираются из различных XML-файлов (XML mapping files).
Экземпляр класса Configuration можно получить путем прямой инициализации. Вот пример настройки хранилища данных из отображений/мэппингов, описанных в двух конфигурационных XML-файлах (в classpath):
Configuration cfg = new Configuration() .addFile("Item.hbm.xml") .addFile("Bid.hbm.xml");
Загрузить файл отображения (mapping file), используя getResourceAsStream() -- другой (иногда даже лучший) способ:
Configuration cfg = new Configuration() .addClass(org.hibernate.auction.Item.class) .addClass(org.hibernate.auction.Bid.class);
В этом случае Hibernate ищет в classpath файлы отображения/мэппингов, названные /org/hibernate/autcion/Item.hbm.xml и /org/hibernate/autcion/Bid.hbm.xml. Этот подход устраняет любые жестко закодированные имена файлов.
Экземпляр класса Configuration также специфицирует различные опциональные свойства:
Properties props = new Properties(); ... Configuration cfg = new Configuration() .addClass(org.hibernate.auction.Item.class) .addClass(org.hibernate.auction.Bid.class) .setProperties(props);
Экземпляр класса Configuration задуман как объект времени конфигурации (configuration-time): создается во время конфигурации и уничтожается как только построен экземпляр класса SessionFactory.
Когда экземпляр класса Configuration разберет (parse) все отображения/мэппинги, приложение получает фабрику (factory) для экземпляров класса Session. Эта фабрика должна быть распределена (shared) между всеми потоками приложения:
SessionFactory sessions = cfg.buildSessionFactory();
Тем не менее, Hibernate дает возможность вашему приложению инстанциировать более одного класса SessionFactory, что очень полезно, если вы используете больше чем одну базу данных.
Класс SessionFactory может открывать экземпляр класса Session по JDBC соединению, осуществляемому пользователем. Эта схема дает возможность приложению осуществлять JDBC соединение когда угодно:
java.sql.Connection conn = datasource.getConnection(); Session session = sessions.openSession(conn); // do some data access work
Чтобы не открыть два параллельных экземпляра класса Session при одном JDBC соединении, необходимо быть внимательным!
В качестве альтернативы вы можете использовать JDBC-соединения, открытые SessionFactory. При конфигурации экземпляра SessionFactory, ему должны быть предоставлены свойства JDBC-соединений, одним из следующих способов:
Передайте экземпляр класса java.util.Properties методу Configuration.setProperties().
Поместите экземпляр класса hibernate.properties в корневой каталог classpath.
Установите Системные своства следующим способом java -Dproperty=value.
Используйте XML-элементы <property> в файле hibernate.cfg.xml (обсуждается ниже).
Используя этот подход, открыть экземпляр класса Session так же просто как:
Session session = sessions.openSession(); // open a new Session // do some data access work, a JDBC connection will be used on demand
Все имена и семантика свойств Hibernate указаны в классе net.sf.hibernate.cfg.Environment. Мы опишем наиболее важные установки для конфигурации JDBC соедининия.
Hibernate получает (и помещает в пул) соедининия, используя экземпляр класса java.sql.DriverManager, если вы утанавливаете следующие свойства:
Таблица 3.1. Hibernate JDBC-cвойства (Properties)
Имя свойства | Назначение |
---|---|
hibernate.connection.driver_class | класс JDBC-драйвера |
hibernate.connection.url | JDBC URL |
hibernate.connection.username | имя пользователя базы данных |
hibernate.connection.password | пароль пользователя базы данных |
hibernate.connection.pool_size | максимальное число соединений в пуле |
Собственный алгоритм помещения соединений в пул (connection pooling algorithm) у Hibernate довольно прост. Его назначение помочь пользователю как можно быстрее начать использовать Hibernate без дополнительных настроек и он не предназначен для использования в рабочих системах, а также для тестирования производительности. Используйте третьесторонний пул соединений для наилучшей производительности и стабильности, т.е. замените свойство hibernate.connection.pool_size определенными настройками пула соединений.
С3PO -- JDBC пул соединений с открытыми исходными кодами (open source connection pool), распространяемый вместе с Hibernate в каталоге lib. Hibernate будет использовать встроенный провайдер соединений C3P0ConnectionProvider для пула, если вы установите свойства hibernate.c3p0.*. Также существует встроенная поддержка для Apache DBCP и Proxool. Для того чтобы использовать DBCPConnectionProvider, вы должны установить свойства DBCP пула соединений hibernate.dbcp.*. Кэширование подговленных JDBC-выражений (prepared statement caching) включается (очень рекомендуем) если установлены следующие свойства hibernate.dbcp.ps.* (DBCP statement cache properties). Для разъяснения этих свойств, пожалуйста обратитесь к документации по Apache commons-pool. Для использования Proxool, вы должны установить свойства hibernate.proxool.*.
Вот пример использования C3PO:
hibernate.connection.driver_class = org.postgresql.Driver hibernate.connection.url = jdbc:postgresql://localhost/mydatabase hibernate.connection.username = myuser hibernate.connection.password = secret hibernate.c3p0.minPoolSize=5 hibernate.c3p0.maxPoolSize=20 hibernate.c3p0.timeout=1800 hibernate.c3p0.max_statement=50 hibernate.dialect = net.sf.hibernate.dialect.PostgreSQLDialect
Для использования внутри сервера приложений, Hibernate может получить соединения из зарегистрированного в JNDI javax.sql.Datasource. Установите следующие свойства:
Таблица 3.2. Свойства Источника Данных Hibernate (Hibernate Datasource Properties)
Имя свойства | Назначение |
---|---|
hibernate.connection.datasource | JNDI-имя источника данных |
hibernate.jndi.url | URL, указывающий на JNDI-провайдера (опционально) |
hibernate.jndi.class | JNDI-класс InitialContextFactory (опционально) |
hibernate.connection.username | пользователь базы данных (опционально) |
hibernate.connection.password | пароль пользователя базы данных (опционально) |
Вот пример использования источника данных предоставляемого через JNDI (JNDI datasource) сервером приложений:
hibernate.connection.datasource = java:/comp/env/jdbc/MyDB hibernate.transaction.factory_class = \ net.sf.hibernate.transaction.JTATransactionFactory hibernate.transaction.manager_lookup_class = \ net.sf.hibernate.transaction.JBossTransactionManagerLookup hibernate.dialect = \ net.sf.hibernate.dialect.PostgreSQLDialect
JDBC-соединения полученные из JNDI-источника данных, будут автоматически участвовать в транзакциях управляемых контейнером (container-managed transactions) сервера приложений.
Произвольные свойства JDBC-соединения могут быть заданы путем добавления "hibernate.connnection" к имени свойства. Например, вы можете указать charSet, используя следующее свойтсво hibernate.connnection.charSet.
Вы можете определить свой собственный, встраеваемый механизм (plugin) получения JDBC-соединений, реализуя интерфейс net.sf.hibernate.connection.ConnectionProvider. Установить желаемую реализацию net.sf.hibernate.connection.ConnectionProvider можно через свойство hibernate.connection.provider_class.
Сушествует большое количество других свойств, которые контролируют поведение Hibernate во время исполнения (runtime). Они необязательны и имеют разумные значения по умолчанию.
Свойства системного уровня могут быть установлены только через java -Dproperty=value или определены в hibernate.properties, но не с экземпляром класса Properties переданным в Configuration.
Таблица 3.3. Hibernate Configuration Properties
Имя свойства | Назначение |
---|---|
hibernate.dialect |
Имя класса Hibernate Dialect -- подключает определенную
платформозависимую функциональность.
например full.classname.of.Dialect |
hibernate.default_schema |
В сгенерированном SQL устанавливает имя схемы по умолчанию.
например SCHEMA_NAME |
hibernate.session_factory_name |
Экземпляр класса SessionFactory, будет автоматически привязан к этому
имени в JNDI после того, как экземпляр будет создан.
например jndi/composite/name |
hibernate.use_outer_join |
Делает возможной выборку данных с использование внешних соединений (outer join fetching).
Данный параметр нерекомендован к использованию (deprecated), используйте
max_fetch_depth.
например true | false |
hibernate.max_fetch_depth |
Устанавливает максимальную "глубину" дерева выборки данных с использованием
внешних соединений для неколлекционных ассоциаций (one-to-one, many-to-one).
0 отключает выборку данных по умолчанию с
использованием внешних соединений (по умолчанию неограничена).
Set a maximum "depth" for the outer join fetch tree
for single-ended associations (one-to-one, many-to-one).
A 0 disables default outer join fetching.
например рекомендованны значения между 0 и 3 |
hibernate.jdbc.fetch_size | Ненулевое значение определяет JDBC fetch size (вызов Statement.setFetchSize()). |
hibernate.jdbc.batch_size |
Не нулевое значение позволяет Hibernate использовать JDBC2 групповое обновление данных
(JDBC2 batch updates).
например рекомендованны значения между 5 и 30 |
hibernate.jdbc.use_scrollable_resultset |
Дает возможность Hibernate использовать JDBC2 scrollable resultsets. Это свойство
необходимо лишь в случае, использования предоставляемых пользователем
JDBC-соединений, иначе Hibernate использует метаданные соединения (connection metadata).
например true | false |
hibernate.jdbc.use_streams_for_binary |
Использовать потоки когда пишутся/читаются бинарные
или сериализуемые данные в/из JDBC. Это свойство системного уровня
(system-level property).
например true | false |
hibernate.jdbc.use_get_generated_keys |
Позволяет использовать JDBC3 вызов PreparedStatement.getGeneratedKeys()
для того, чтобы получать ключи сгенеренный базой данных (natively generated keys)
после произведенной вставки (SQL insert). Требует JDBC3+ драйвер и JRE1.4+.
Установите данное свойство в false, если ваш драйвер имеет проблемы с генераторами
идентификаторов предоставляемыми Hibernate. По умолчанию Hibernate пытается определить
возможности драйвера используя метаданные соединения.
например true|false |
hibernate.cglib.use_reflection_optimizer |
Позволяет использовать CGLIB вместо стандартного runtime reflection (свойство
системного уровня, по умолчанию, где это возможно, используется CGLIB).
Стандартный reflection может быть полезен при поиске неисправностей.
например true | false |
hibernate.jndi.<propertyName> | Передаёт свойство propertyName в JNDI InitialContextFactory. |
hibernate.connection.isolation |
Устанавливает уровень изоляции JDBC-транзакций (JDBC transaction isolation level).
Посмотрите на документацию к java.sql.Connection для
получения значимых значений, но обратите внимание, что не все базы данных
поддерживают все уровни изоляций.
например 1, 2, 4, 8 |
hibernate.connection.<propertyName> | Передает JDBC-свойство propertyName вызову DriverManager.getConnection(). |
hibernate.connection.provider_class |
Имя класса используемого провайдера соединений, реализующего интерфейс
ConnectionProvider.
например classname.of.ConnectionProvider |
hibernate.cache.provider_class |
Имя класса используемого кэш-провайдера, реализующего интерфейс
CacheProvider.
например classname.of.CacheProvider |
hibernate.cache.use_minimal_puts |
Оптимизировать операции кэша второго уровня (second-level cache),
минимизируя операции записи, ценой более частых считываний (полезно при использовании
кластерных кэшей).
например true|false |
hibernate.cache.use_query_cache |
Позволяет использовать кэш для запросов (query cache). Для каждого из запросов,
использование кэша должно быть установлено программно.
например true|false |
hibernate.cache.region_prefix |
Приставка используемая для имен регионов кэша второго уровня
(A prefix to use for second-level cache region names).
например prefix |
hibernate.transaction.factory_class |
Имя класса реализующего TransactionFactory,
для использования с Hibernate Transaction API
(по умолчанию JDBCTransactionFactory).
например classname.of.TransactionFactory |
jta.UserTransaction |
JNDI-имя, используемое экземпляром класса JTATransactionFactory для
получения JTA UserTransaction от сервера приложений.
например jndi/composite/name |
hibernate.transaction.manager_lookup_class |
Имя класса реализующего TransactionManagerLookup,
требуется когда в JTA-окружении включен кэш уровня JVM
(JVM-level cache = second-level cache)
например classname.of.TransactionManagerLookup |
hibernate.query.substitutions |
Отображения/мэппинги из маркеров Hibernate запросов в SQL маркеры (например, маркеры могут
быть функциональными или литеральными именами (function or literal names)).
Мэппинг/отображение лексем (tokens) из запросов Hibernate в лексемы SQL
(например лексемой могут быть имя функции или буквенная константа).
например hqlLiteral=SQL_LITERAL, hqlFunction=SQLFUNC |
hibernate.show_sql |
Логировать все SQL-выражения на консоль.
например true | false |
hibernate.hbm2ddl.auto |
Автоматически экспортировать DDL-схему в бузу данных,
после создания SessionFactory.
С установленным значением create-drop,
схема базы данных будет удалена, когда SessionFactory
будет закрыта явно (в ручную).
например update | create | create-drop |
Вы всегда должны устанавливать свойство hibernate.dialect в имя класса, который является подклассом net.sf.hibernate.dialect.Dialect для требуемой вам базы данных. Но это не является строгим требованием, если вы не собираетесь использовать следующие генераторы первичных ключей: native или sequence, и не используете пессимистичных блокировок (pessimistic locking), например используя вызовы: Session.lock() или Query.setLockMode(). Однако, если вы указали правильный диалект, Hibernate будет использовать разумные значения параметров, перечисленных выше, освобождая вас от необходимости указывать их вручную.
Таблица 3.4. Диалекты SQL, поддерживаемые Hibernate (hibernate.dialect)
Реляционная СУБД | Диалект |
---|---|
DB2 | net.sf.hibernate.dialect.DB2Dialect |
MySQL | net.sf.hibernate.dialect.MySQLDialect |
SAP DB | net.sf.hibernate.dialect.SAPDBDialect |
Oracle (любой версии) | net.sf.hibernate.dialect.OracleDialect |
Oracle 9 | net.sf.hibernate.dialect.Oracle9Dialect |
Sybase | net.sf.hibernate.dialect.SybaseDialect |
Sybase Anywhere | net.sf.hibernate.dialect.SybaseAnywhereDialect |
Progress | net.sf.hibernate.dialect.ProgressDialect |
Mckoi SQL | net.sf.hibernate.dialect.MckoiDialect |
Interbase | net.sf.hibernate.dialect.InterbaseDialect |
Pointbase | net.sf.hibernate.dialect.PointbaseDialect |
PostgreSQL | net.sf.hibernate.dialect.PostgreSQLDialect |
HypersonicSQL | net.sf.hibernate.dialect.HSQLDialect |
Microsoft SQL Server | net.sf.hibernate.dialect.SQLServerDialect |
Ingres | net.sf.hibernate.dialect.IngresDialect |
Informix | net.sf.hibernate.dialect.InformixDialect |
FrontBase | net.sf.hibernate.dialect.FrontbaseDialect |
Если ваша база данных поддерживает внешние соединения (outer joins) в стиле ANSI или Oracle, выборка данных с использованием внешних соединений (outer join fetching) может увеличить производительность вашего приложения, путем ограничения числа полных обходов дерева поиска (возможно, ценой увеличения нагружки на базу данных, т.к. часть работы перекладывается на нее). Выборка данных с использованием внешних соединений, позволяет выбирать данные для графа объектов, соединенных посредством many-to-one, one-to-many или one-to-one ассоциаций, используя всего один SQL SELECT запрос.
Загруженный граф объектов заканчивается "листьями". По умолчанию, в качестве "листьев" выступают "крайние" в ассоции объекты, коллекции, объекты с установленным "заместителем" -- прокси (proxy) или объекты с циклическими ссылками.
Для определенной ассоциации, выборка данных может быть разрешена или запрещена (а поведение по умолчанию изменено) установкой атрибута outer-join в XML-мэппинге (XML mapping).
Выборка данных с использованием внешних соединений, может быть отключена глобально, установкой свойства hibernate.max_fetch_depth в 0. Установка данного свойства в 1 или выше включает использование внешних соединений при выборке данных для всех one-to-one и many-to-one ассоциаций, у которых атрибут outer-join установлен в значение по умолчанию auto. Тем не мене, one-to-many ассоциации и коллекции, выбираются с использованием внешних соединений, только при явно установленном атрибуте outer-join в true. Данное поведение может быть изменено во время исполнения запросов Hibernate.
Изменение сконфигурированных внешних соединений может производиться через использование полных выборок данных (EAGER FETCH>), в HQL, используя LEFT JOIN FECH конструкцию, в Criteria API -- Criteria.setFetchMode().
Oracle ограничивает размер byte-массивов, которые могут быть переданы через их JDBC- драйвер. Если вы хотите использовать большие экземпляры типов binary или serializable, вам нужно включить свойство hibernate.jdbc.use_streams_for_binary. Это свойство уровня JVM.
Вы можете интегрировать кэш-систему уровня JVM, так же называемый кэш второго уровня (second-level cache) также вы можете реализовать кластерный кэш, реализуя интерфейс net.sf.hibernate.cache.CacheProvider. Вы можете использовать желаемую реализацию, установив свойство hibernate.cache.provider_class.
Если вы желаете использовать Hibernate Transaction API, вы должны указать класс фабрики (factory class) для экземпляров Transaction, установив свойство hibernate.transaction.factory_class. Hibernate Transaction API скрывает нижележащий механизм транзакций и позволяет коду Hibernate исполняться как в управляемом контейнером (container managed), так и в неуправляемом окружении.
Кэш первого кровня (first-level cache) -- это Hibernate Session.
Существует 2 стандартных (встроенных) выбора:
все вызовы делегируются вызовам JDBC-транзакций, используются транзакции базы данных (по умолчанию)
вызовы делегируются JTA (если на момент вызова, транзакция уже существует, Session выполняет свою работу в контексте этой транзакции, иначе стартуется новая транзакция).
Также вы можете определить свою собственную стратегию транзакций (например для службы транзакций CORBA).
Если, в JTA окружении, вы хотите использовать кэширование уровня JVM для изменяемых данных (mutable data), вы должны специфицировать стратегию получения менеджера транзакций JTA, TransactionManager, так как он не стандартизирован для J2EE контейнеров:
Таблица 3.5. Менеджеры транзакций JTA
Фабрика Транзакций (Transaction Factory) | Сервер Приложений |
---|---|
net.sf.hibernate.transaction.JBossTransactionManagerLookup | JBoss |
net.sf.hibernate.transaction.WeblogicTransactionManagerLookup | Weblogic |
net.sf.hibernate.transaction.WebSphereTransactionManagerLookup | WebSphere |
net.sf.hibernate.transaction.OrionTransactionManagerLookup | Orion |
net.sf.hibernate.transaction.ResinTransactionManagerLookup | Resin |
net.sf.hibernate.transaction.JOTMTransactionManagerLookup | JOTM |
net.sf.hibernate.transaction.JOnASTransactionManagerLookup | JOnAS |
net.sf.hibernate.transaction.JRun4TransactionManagerLookup | JRun4 |
Экземпляр класса SessionFactory, привязанный к JNDI, может упростить поиск фабрики и создание новых сессий (объекты класса Session).
Если вы хотите привязать экземпляр класса SessionFactory к JNDI-пространству имен, укажите имя (например, java:comp/env/hibernate/SessionFactory), используя свойство hibernate.session_factory_name. Если это свойство не указано, SessionFactory не будет привязан к JNDI. (Это особенно полезно в окружениях с реализацией JNDI только-на-чтение, например Tomcat.)
Для привязывания экземпляра класса SessionFactory к JNDI, Hibernate использует значения свойств hibernate.jndi.url, hibernate.jndi.class для инстанционирования инициализационного контекста (initial context). Если данные свойства не указаны, то будет использован InitialContext по умолчанию.
Если вы решили использовать JNDI, то EJB или какой-нибудь вспомогательный класс, могут получить SessionFactory используя поиск по JNDI (JNDI lookup).
Используя свойство hibernate.query.substitutions, вы можете определить новые лексемы (tokens) для запросов Hibernate. Например:
hibernate.query.substitutions true=1, false=0
приведет к тому что значения true и false, в SQL-запросе, будут заменены целочисленными литералами (integer literals).
hibernate.query.substitutions toLowercase=LOWER
позволит вам переименовать SQL-функцию LOWER.
Hibernate логирует различные события, используя библиотеку Apache commons-logging.
Библиотека commons-loggins перенаправляет логируемые события либо к Apache Log4j (если вы поместили log4j.jar в ваш classpath), либо к механизму логирования JDK1.4 (если вы используете JDK1.4 или выше). Вы можете загрузить библиотеку Log4j с сайта http://jakarta.apache.org. Для использования Log4j вы должны поместить файл сойств log4j.properties в ваш classpath, пример такого файла поставляется с Hibernate в каталоге src/.
Мы настоятельно рекомендуем вам ознакомиться с сообщениями логируемыми Hibernate. Было выполнено много работы, для чтобы сделать эти сообщения как можно более детальными, описательеными и удобными для чтения. Логирование является необходимым средством при поиске неисправностей. Так же не забудьте подключить логирование SQL-запросов, как это описано выше (hibernate.show_sql), это первый шаг который вы должны выполнить при поиске проблем с производительностью.
Интерфейс net.sf.hibernate.cfg.NamingStrategy позволяет вам указать "стандарт именований" ("naming standard") для объектов базы данных и элементов схемы.
Вы можете предоставить правила для именования идентификаторов базы данных на основе Java-идентификаторов. Эти правила будут использоваться при автоматической генерации схемы базы данных или при обработке заданных в файле мэппинга "логических" имен колонок и таблиц в "физические" имена. Эта особенность позволяет уменьшить многословность документов мэппинга, удаляет повторяющиеся "помехи" (repetitive noise), например в виде префиксов к именам таблиц TBL_ и делает файлы мэппинга более читабельными. Стратегия по умолчанию, используемая Hibernate, достаточно минимальная.
Вы можете указать различные стратегии вызвав метод Configuration.setNamingStrategy(), перед добавлением мэппингов:
SessionFactory sf = new Configuration() .setNamingStrategy(ImprovedNamingStrategy.INSTANCE) .addFile("Item.hbm.xml") .addFile("Bid.hbm.xml") .buildSessionFactory();
Стратегия именования net.sf.hibernate.cfg.ImprovedNamingStrategy, является встроенной стратегией и может быть использована в какчестве начальной точки для некоторых приложений.
Имеется альтернативный подход для конфигурирования Hibernate, это указать все настройки в файле названном hibernate.cfg.xml. Этот файл может быть использован для замещения файла hibernate.properties или если присутствуют оба файла, то для переопределения свойств указанных в hibernate.properties.
Ожидается, что конфигурационный XML-файл размещен в коревом каталоге вашего CLASSPATH. Вот пример файла hibernate.cfg.xml:
<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 2.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"> <hibernate-configuration> <!-- a SessionFactory instance listed as /jndi/name --> <session-factory name="java:comp/env/hibernate/SessionFactory"> <!-- properties --> <property name="connection.datasource">my/first/datasource</property> <property name="dialect">net.sf.hibernate.dialect.MySQLDialect</property> <property name="show_sql">false</property> <property name="use_outer_join">true</property> <property name="transaction.factory_class"> net.sf.hibernate.transaction.JTATransactionFactory </property> <property name="jta.UserTransaction">java:comp/UserTransaction</property> <!-- mapping files --> <mapping resource="org/hibernate/auction/Item.hbm.xml"/> <mapping resource="org/hibernate/auction/Bid.hbm.xml"/> </session-factory> </hibernate-configuration>
Теперь для конфигурирования Hibernate надо просто выполнить следующий код
SessionFactory sf = new Configuration().configure().buildSessionFactory();
Вы можете выбрать другой конфигурационный XML-файл используя
SessionFactory sf = new Configuration() .configure("catdb.cfg.xml") .buildSessionFactory();
Долгоживущие классы (Persistent сlasses) - это классы приложения, реализующие сущности бизнес-задачи (например, Заказчик, Счет в приложениях электронной коммерции). Долгоживущий класс, как видно из названия, имеет временное и постоянное представления (постоянное представление - представление класса, использующееся для сохранения экземпляра этого класса, например, в базе данных; временное представление - экземпляр класса в приложении, т.е. объект времени выполнения в JVM).
Для того чтобы воспользоваться всеми приемуществами технологии Hibernate, рекомендуется использовать POJO (Plain Old Java Object) модель программирования при создании долгоживущих классов.
В качестве демонстрации приведем пример долгоживущего класса, стурктура которого является наиболее часто используемой при программировании.
package eg; import java.util.Set; import java.util.Date; public class Cat { private Long id; // идентификатор private String name; private Date birthdate; private Cat mate; private Set kittens private Color color; private char sex; private float weight; private void setId(Long id) { this.id=id; } public Long getId() { return id; } void setName(String name) { this.name = name; } public String getName() { return name; } void setMate(Cat mate) { this.mate = mate; } public Cat getMate() { return mate; } void setBirthdate(Date date) { birthdate = date; } public Date getBirthdate() { return birthdate; } void setWeight(float weight) { this.weight = weight; } public float getWeight() { return weight; } public Color getColor() { return color; } void setColor(Color color) { this.color = color; } void setKittens(Set kittens) { this.kittens = kittens; } public Set getKittens() { return kittens; } // addKitten not needed by Hibernate public void addKitten(Cat kitten) { kittens.add(kitten); } void setSex(char sex) { this.sex=sex; } public char getSex() { return sex; } }
Следует соблюдать следующие четыре плавила:
Класс Cat представляет методы доступа для всех сохраняемых полей. Многие другие ORM (Object Relational Model - объектно-реляционная модель) инструменты напрямую сохраняют переменные объекта долгоживущего класса. Мы думаем, что значительно лучше будет отделить детали реализации от механизма сохранения объекта. Hibernate работает со свойствами объектов в стиле JavaBeans и распознает имена методов в форме getFoo, isFoo и setFoo.
В отличие от объектов JavaBeans, методы доступа к свойствам объектов долгоживущих классов не обязаны быть публичными (public) - Hibernate может работать со свойствами, методы доступа к которым объявлены с модификаторами "по умолчанию", protected или private.
Класс Cat имеет неявный конструктор по умолчанию (конструктор без аргументов). Для корректной работы Hibernate все долгоживущие классы должны иметь такой конструктор (который может быть не public) для того, чтобы Hibernate мог создавать объекты этих классов с использованием Constructor.newInstance().
Класс Cat имеет свойство под названием "id". Это свойство содержит значение столбца первичного ключа в таблице базы данных. Такое свойство может называться любым именем, и иметь любой примитивный тип, тип класса-обертки примитивного типа, а также типы java.lang.String и java.util.Date. Если ваши старые таблицы содержат составные ключи, вы можете использовать определенный пользователем класс со свойствами этих типов (см. ниже раздел, посвященный составным идентификаторам).
Свойство-идентификатор не является обязательным для класса и может отсуствовать. Вы можете не создавать его и дать Hibernate самостоятельно следить за идентификацией объекта, однако многие приложения пользуются такими свойствами и на данный момент такое решение широко распространено.
Более того, некоторая функциональность недоступна для классов, которые не имеют явно определенных идентификаторов. В частности:
Каскадное обновление (см. "Объекты жизненного цикла")
Session.saveOrUpdate()
Мы рекомендуем использовать в persistent-классах свойство-идентификатор с фиксированным названием, которое имеет непримитивный тип (чтобы оно могло принимать значение null)
Центральным элементом технологии Hibernate являются proxy-классы, которые опираются на возможность наследования от определенных пользователем долгоживущих классов или реализации соответствующих интерфейсов, задающих набор persistent-свойств через публичные set/get методы.
С помощью Hibernate Вы можете сохранять и работать с final-классами, не реализующими интерфейсов, однако вы не сможете использовать proxy-классы, что некоторым образом ограничит Ваши возможности по настройке быстродействия.
Подкласс также должен соблюдать первое и второе правила. Cвойство-идентификтор Наследуется у класса-родителя Cat.
package eg; public class DomesticCat extends Cat { private String name; public String getName() { return name; } protected void setName(String name) { this.name=name; } }
Вы должны переопределить методы equals() и hashCode() если предполагается использование объектов долгоживущих классов в качестве элементов коллекций или хэш-таблиц (например, в качестве элементов в наборе Set).
Это требование предъявляется только в случае, если объекты загружены в разных Hibernate-сессиях, т.к. Hibernate гарантирует JVM-идентичность ( a == b , реализация метода equals() по умолчанию) только в рамках одной сессии!
Фраза "гарантирует JVM-идентичность" означает, что если в какой-то момент через некоторую сессию был получен некоторый объект с идентификатором, например, "5", во в последующие моменты при повторном получении через ту же сессию этого объекта с этим идентификатором, сессия возвратит тот же экземпляр класса, если только приложение не удалит этот экземпляр из сессии самостоятельно (прим. пер.).
Даже если оба объекта a и b представляют одну и ту же запись в базе данных (т.е. имеют одно и то же значение первичного ключа в качестве идентификатора), мы не можем гарантировать, что они являются одним и тем же экземпляром вне в разных сессиях.
Наиболее очевидный способ реализации equals()/hashCode(), который сразу приходит в голову, это сравнивать значения идентификаторов объектов. Если значения совпадают, то оба объекта представляют одну и ту же запись в базе данных, и таким образом, они эквивалентны (то есть, если оба эти объекта будут добавлены в коллекцию Set, то только один из них в ней будет присутствовать). К сожалению, мы не можем использовать этот подход. Hibernate присваивает значения идентификаторам только уже сохраненных объектов - новые объекты не имеют этого идентификатора до тех пор, пока они не будут сохранены в базу данных! Мы рекомендуем реализовывать методы equals() и hashCode() используя семантику значений, хранящихся в объекте persistent-класса (т.н. Business key equality - эквивалентность по бизнес-ключу).
Эквивалентность по бизнес-ключу означает, что метод equals() сравнивает только те свойства, которые идентифицируют объект в реальном мире (составляющие т.н. потенциальный естественный ключ).
public class Cat { ... public boolean equals(Object other) { if (this == other) return true; if (!(other instanceof Cat)) return false; final Cat cat = (Cat) other; if (!getName().equals(cat.getName())) return false; if (!getBirthday().equals(cat.getBirthday())) return false; return true; } public int hashCode() { int result; result = getName().hashCode(); result = 29 * result + getBirthday().hashCode(); return result; } }
Помните, что наш потенциальный ключ (в данном случае это имя и день рождения) должен лишь подходить для конкретной операции сравнения (возможно, что только в одном-единственном случае - при использовании в методе equals()), т.к. нам не нужна реализация требований стабильности, обычно предъявляемых к первичным ключам.
При необходимости, долгоживущий класс может реализовать интерфейс Lifecycle, который объявляет некоторые callback-методы, позволяющие объектам долгоживущих классов совершать необходимые действия по инициализации или отчистке после сохранения или загрузки и перед удалением или обновлением объекта.
В добавление к Lifecycle интерфейс Interceptor предоставляет более независимую от бизнес-логики альтернативу.
public interface Lifecycle { public boolean onSave(Session s) throws CallbackException; (1) public boolean onUpdate(Session s) throws CallbackException; (2) public boolean onDelete(Session s) throws CallbackException; (3) public void onLoad(Session s, Serializable id); (4) }
(1) | onSave - вызывается непосредственно перед сохранением объекта в базу данных |
(2) | onUpdate - вызывается непосредственно перед обновлением объекта (когда объект передается в метод Session.update()) |
(3) | onDelete - вызывается непосредственно перед удалением объекта |
(4) | onLoad - вызывается сразу после загрузки объекта |
Методы onSave(), onDelete() и onUpdate() могут использоваться для каскадного сохранения и удаления зависимых объектов, что эквивалентно объявлению каскадных операций в mapping-файле. Метод onLoad() может использоваться для инициализации transient-свойств (т.е. свойств, которые не записываются в базу при сохранении объекта, прим. пер.) на основе доступных долгоживущих свойств. Этот метод не может использоваться для загрузки зависимых объектов, т.к. Hibernate запрещает вызывать методы сессии из onLoad(). Методы onLoad(), onSave() и onUpdate() могут также сохранять ссылку на текущую сессию для дальнейшего использования.
Имейте в виду, что метод onUpdate() вызывается только тогда, когда объект передается в Session.update(), а не при изменении свойств объекта.
Если методы onSave(), onUpdate() или onDelete() возвращают true, то операция прерывается без ошибки. Если при исполнении этих методов пробрасывается исключение CallbackException, то операция прерывается, а исключение передается обратно в приложение.
Если не используется родная генерация ключей (native key generation), то метод onSave() вызывается после того, как объекту назначается идентификатор.
Если необходимо чтобы долгоживущий класс проверял выполнение некоторых условий перед сохранением, разработчик может реализовать в persistent-классе интерфейс Validatable:
public interface Validatable { public void validate() throws ValidationFailure; }
Объект должен бросить исключение ValidationFailure если какое-то из условий сохранения нарушено. Объект класса, реализующего интерфейс Validatable не должен менять свое состояние в процессе проверки (validate()).
В отличие от callback-методов интерфейса Lifecycle, время вызова метода validate() не определено. Бизнес-логика приложения не должна полагаться на вызовы validate().
В следующей главе мы покажем, как задается соответствие между классами и структурой базы данных с помощью mapping-файлов в простом, удобном для чтения XML формате. Многие пользователи Hibernate предпочитают определять эти соответствия прямо в исходном коде классов, используя XDoclet @hibernate.tags. В этом документе мы не будем описывать этот подход, т.к., строго говоря, это часть XDoclet документации. Тем не менее, ниже мы приведем пример класса Cat с XDoclet описанием.
package eg; import java.util.Set; import java.util.Date; /** * @hibernate.class * table="CATS" */ public class Cat { private Long id; // идентификатор private Date birthdate; private Cat mate; private Set kittens private Color color; private char sex; private float weight; /** * @hibernate.id * generator-class="native" * column="CAT_ID" */ public Long getId() { return id; } private void setId(Long id) { this.id=id; } /** * @hibernate.many-to-one * column="MATE_ID" */ public Cat getMate() { return mate; } void setMate(Cat mate) { this.mate = mate; } /** * @hibernate.property * column="BIRTH_DATE" */ public Date getBirthdate() { return birthdate; } void setBirthdate(Date date) { birthdate = date; } /** * @hibernate.property * column="WEIGHT" */ public float getWeight() { return weight; } void setWeight(float weight) { this.weight = weight; } /** * @hibernate.property * column="COLOR" * not-null="true" */ public Color getColor() { return color; } void setColor(Color color) { this.color = color; } /** * @hibernate.set * lazy="true" * order-by="BIRTH_DATE" * @hibernate.collection-key * column="PARENT_ID" * @hibernate.collection-one-to-many */ public Set getKittens() { return kittens; } void setKittens(Set kittens) { this.kittens = kittens; } // addKitten not needed by Hibernate public void addKitten(Cat kitten) { kittens.add(kitten); } /** * @hibernate.property * column="SEX" * not-null="true" * update="false" */ public char getSex() { return sex; } void setSex(char sex) { this.sex=sex; } }
Объектно-реляционный маппинг описывается в виде XML документа. Документ описывающий маппинг проектировался как легко читаемый и ориентированный на ручное редактирования. Язык описания маппинга ориентирован на Java, это означает что маппинг констуируются вокруг объявлений персистентных java-классов, а не таблиц БД.
Несмотря на то, что большинство пользователей Hibernate определяют и редактируют маппинги в XML вручную, существует некоторое количество инструментов для генерации документов описывающих маппинги. В качестве примеров можно привести XDoclet, Middlegen и AndroMDA.
Начнем с примера описания маппинга:
<?xml version="1.0" encoding="windows-1251"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <hibernate-mapping package="eg"> <class name="Cat" table="CATS" discriminator-value="C"> <id name="id" column="uid" type="long"> <generator class="hilo"/> </id> <discriminator column="subclass" type="character"/> <property name="birthdate" type="date"/> <property name="color" not-null="true"/> <property name="sex" not-null="true" update="false"/> <property name="weight"/> <many-to-one name="mate" column="mate_id"/> <set name="kittens"> <key column="mother_id"/> <one-to-many class="Cat"/> </set> <subclass name="DomesticCat" discriminator-value="D"> <property name="name" type="string"/> </subclass> </class> <class name="Dog"> <!-- Здесь описывается маппинг для собаки --> </class> </hibernate-mapping>
Мы не будем рассматривать содержание документа маппинга. Мы опишем только те элементы и атрибуты документа, которые используются Hibernate в процессе работы. Приведенный выше документ маппинга среди прочего содержит атрибуты и элементы которые используются при генерации схемы базы данных, например атрибут not-null.
Все XML документы описывающие маппинги должны содержать определение типа документа (doctype). Актуальный DTD может быть найден по URL, определенному выше, в директории hibernate-x.x.x/src/net/sf/hibernate или в файле hibernate.jar. Hibernate всегда сначала ищет DTD в classpath.
Элемент имеет три необязательных атрибута. Атрибут schema определяет схему, в терминах СУБД, к которой относятся таблицы описываемые в документе маппинга. Если атрибут указан, Hibernate всегда именует таблицы с указанием схемы, в противном случае, имена таблиц формируются без указания схемы. Атрибут default-cascade определяет правила каскадов для свойств и коллекций, в описании которых явно не определен атрибут cascade. Атрибут auto-import позволяет использовать неполные имена классов (без имени пакета) в языке запросов.
<hibernate-mapping schema="schemaName" (1) default-cascade="none|save-update" (2) auto-import="true|false" (3) package="package.name" (4) />
(1) | schema (необязательный): Наименование схемы БД. |
(2) | default-cascade (необязательный - по умолчанию none): Правила каскадов по умолчанию. |
(3) | auto-import (необязательный - по умолчанию true): Определяет возможность использования неполных имен классов (описанных в данном документе) в языке запросов. |
(4) | package (необязательный): Префикс пакета для определения полного наименования классов. |
Необходимо устанавливать auto-import="false", если существует два или более персистентных класса с одинаковыми наименованиями (без учета имени пакета). Если Hibernate обнаружит два класса в разных пакетах соответсвующих указаному имени, при разборе файла маппинга будет сгенерировано исключение.
Персистентные классы определяются в элементе class:
<class name="ClassName" (1) table="tableName" (2) discriminator-value="discriminator_value" (3) mutable="true|false" (4) schema="owner" (5) proxy="ProxyInterface" (6) dynamic-update="true|false" (7) dynamic-insert="true|false" (8) select-before-update="true|false" (9) polymorphism="implicit|explicit" (10) where="arbitrary sql where condition" (11) persister="PersisterClass" (12) batch-size="N" (13) optimistic-lock="none|version|dirty|all" (14) lazy="true|false" (15) />
(1) | name: Полное наименование Java класса персистентного класса или интерфейса. |
(2) | table: Наименование таблицы БД. |
(3) | discriminator-value (необязательный - по умолчанию имя класса): Значение для определения индивидуальных подклассов. Используется при полиморфизме. Допустимые значения включают null и not null |
(4) | mutable (необязательный, по умолчанию true): Используется для определения (не)изменчивости класса (mutable/not mutable) |
(5) | schema (необязательный): Переопределяет наименование схемы которая была специфицирована в корневом элементе <hibernate-mapping>. |
(6) | proxy (необязательный): Определяет интерфейс используемый для ленивой инициализации прокси-класса. В качестве прокси-класса можно использовать тот же (персистетный) класс. |
(7) | dynamic-update (необязательно, по умолчанию false): Если параметр установлен в true Hibernate будет генерировать UPDATE запрос в процессе выполнения, при этом запрос будет сгенерирован только на те столбцы, которые были изменены. |
(8) | dynamic-insert (необязательный, по умолчанию false): Если параметр установлен в true Hibernate будет генерировать INSERT запрос в процессе выполнения, при этом запрос будет сгенерирован только на те столбцы, значение которых не null. |
(9) | select-before-update (необязательный, по умолчанию false): Обязывает Hibernate перед выполнением SQL UPDATE всегда проверять действительно ли изменился объект. В определенных случаях (в действительности, только когда трансиентный объект ассоциируется с новой сессией с использованием update()), это означает что Hibernate генерирует SQL SELECT чтобы убедиться в том, что UPDATE действительно необходим. |
(10) | polymorphism (необязательный, по умолчанию implicit): Определяет использования явного (explicit) или неявного (implicit) полиморфизма. |
(11) | where (необязательный) определяет произвольное условие WHERE SQL запроса, который используется для получения обьектов определяемого класса. |
(12) | persister (необязательный): Используется для указания реализации ClassPersister. |
(13) | batch-size (необязательный, по умолчанию 1) определяет "размер пакета (batch size)" для выборки экземпляров определяемого класса по идентификатору. |
(14) | optimistic-lock (необязательный, по умолчанию version): Устанавливает стратегию оптимистического блокирования (optimistic locking) |
(15) | lazy (необязательный): Установка атрибута lazy="true" является эквивалентом установки интерфеса прокси на себя (смотри атрибут proxy). |
Совершенно корректно использование java интерфейса в качестве персистентного класса. Реализации инфтрфейса можно определить при помощи элемента <subclass>. Так же возможно использование статических внутренних классов (static inner class), при этом следует использовать стандартную форму наименоваия класса (например eg.Foo$Bar)
Неизменяемые классы (immutable classes), с установленым атрибутом mutable="false" не могут быть изменены или удалены приложением. Это позволяет Hibernate немного оптимизировать скорость работы с такими классами.
Необязательный атрибут proxy разрешает ленивую инициализацию экземпляров персистентного класса. Изначально Hibernate возвращает CGLIB прокси, реализующие указанный интерфейс, и только после первого вызова метода прокси интерфейса загружается сам персистентный класс. Смотри так же раздел "Прокси для ленивой инициализации" ниже.
Неявный (implicit) полиморфизм означает что экземпляры класса будут созданы для запроса по любому суперклассу или реализованному персистентным классом интерфейсу. Явный (explicit) полиморфизм означает, что экземпляры класса будут создаваться только при запросах с явным указанием имени персистентного класса. TODO: Implicit polymorphism means that instances of the class will be returned by a query that names any superclass or implemented interface or the class and that instances of any subclass of the class will be returned by a query that names the class itself. Explicit polymorphism means that class instances will be returned only be queries that explicitly name that class and that queries that name the class will return only instances of subclasses mapped inside this <class> declaration as a <subclass> or <joined-subclass>. For most purposes the default, polymorphism="implicit", is appropriate. Explicit polymorphism is useful when two different classes are mapped to the same table (this allows a "lightweight" class that contains a subset of the table columns).
Атрибут persister позволяет настроить стратегию персистенции для класса. Например, вы можете написать свою реализацю net.sf.hibernate.persister.EntityPersister или же совершенно иную реализацию интерфейса net.sf.hibernate.persister.ClassPersister которая будет реализовывать персистенцию, через, например, вызов хранимых процедур, сериализацию в файловую струкуру или LDAP. Смотри для примера net.sf.hibernate.test.CustomPersister (реализует "персистентность" в Hashtable).
Учтите что установки dynamic-update и dynamic-insert не наследуются подклассами должны быть повторно установлены в элеметах <subclass> или <joined-subclass>. Эти установки могут увеличить производительность в некоторых случаях, но так же возможно и уменьшение производительности в иных случаях. Используйте их рассудительно.
Использование select-before-update обычно уменьшает производительность. Используется, чтобы избежать лишних вызовов тригеров на update.
Если вы включили dynamic-update, у вас есть выбор стратегии оптимистической блокировки (optimistic locking):
version проверять столбец версии/даты
all проверять все столбцы
dirty проверять измененные столбцы
none не использовать оптимистичесую блокировку
Мы очень настойчиво рекомендуем использовать стобцы версии/даты для оптимистической блокировки в Hibernate. Эта стратегия обеспечивает оптимальную производительность и это единственная стратегия обеспечивающая корректное отслеживание изменений, которые производились все контекста сессии (при использовании Session.update()). Помните, что свойство версии или даты никогда не должны быть null, в противном случае, независимо от стратегии unsaved-value, экземляры будут опознаны как трансиентные (transient).
Замеппленые классы должны декларировать столбец первичного ключа в таблице базы данных. Большинство классов так же определяют JavaBean свойсвтво хранящее уникальный идентификатор экземпляра. Элемент <id> определяет маппинг этого свойства к первичному ключу таблицы.
<id name="propertyName" (1) type="typename" (2) column="column_name" (3) unsaved-value="any|none|null|id_value" (4) access="field|property|ClassName"> (5) <generator class="generatorClass"/> </id>
(1) | name (необязательный): Наименование свойства идентификатора. |
(2) | type (необязательный): Имя определяющее Hibernate-тип свойства. |
(3) | column (необязательно - по умолчанию имя свойства): Имя столбца - первичного ключа таблицы. |
(4) | unsaved-value (необязательно - по умолчанию null): Значени свойства идентификатора, которое обзначает, что экземпляр новый (в терминах персистентного хранилища). Отличает экземпляр от других трансиентных экземпляров, которые были загружены или сохранены в предыдущей версии. |
(5) | access (необязательный - по умолчанию property): Стратегия, которую должен использовать Hibernate для доступа к значению свойства. |
Если атрибут name не указан, предполагается, что класс не имеет свойства идентификатора.
Атрибут unsaved-value важен! Если свойство идентификатор вашего класса по умолчанию не null, вы должны специфицировать реально существующее умолчание для данного свойства.
Существует альтернативное объявление <composite-id> для доступа к унаследованным (legacy) данным c композитными ключами. Мы настойчиво не рекомендуем использовать композитные ключи в других случаях.
Обязательный дочерний элемент <generator>'а определяет Java класс используемый для генерации уникальных идентификаторов экземпляров песистентных классов. При необходимости используется элемент <param> для передачи параметров инициализации или конфигурирации экземпляра генератора.
<id name="id" type="long" column="uid" unsaved-value="0"> <generator class="net.sf.hibernate.id.TableHiLoGenerator"> <param name="table">uid_table</param> <param name="column">next_hi_value_column</param> </generator> </id>
Все генераторы реализуют интерфейс net.sf.hibernate.id.IdentifierGenerator. Это очень простой интерфейс; многие приложения могут использовать свою специальную реализацию генератора. Несмотря на это, Hibernate включает в себя множество встроенных генераторов. Ниже идут краткие наименования (ярлыки) для встроенных генераторов:
генерирует идентификаторы типа long, short или int, уникальные только когда другие процессы не добавляют данные в ту же таблицу. Не использовать в кластере.
Поддерживает identity столбцы в in DB2, MySQL, MS SQL Server, Sybase и HypersonicSQL. Тип возвращаемого идентификатора long, short или int.
Использует sequence в DB2, PostgreSQL, Oracle, SAP DB, McKoi или generator в Interbase. Тип возвращаемого идентификатора long, short или int.
использует hi/lo алгоритм для эффективной генерации идентификаторов которые имеют тип long, short или int, требуют наименования таблицы и столбца (по умолчанию hibernate_unique_key и next_hi соответсвенно), как источник значений hi. Алгоритм hi/lo генерирует идентификаторы которые кникальный только для отдельный баз данных. Не используйте этот генератор для соединений через JTA или пользовательских соединений.
использует алгоритм hi/lo для эффективной генерации идентификаторов типа long, short или int, с использованием последовательности (sequence) базы данных.
Использует 128-битный UUID алгоритм для генерации строковых идентификаторов, уникальных в сети (изспользуется IP-адрес). UUID - строка длинной в 32 символа, содержащая шеснадцатеричное представление числа.
использует тот же UUID алгоритм, однако строка при использовании этого генератора состоит из 16 (каких-то) ANSII символов. Не использовать с PostgreSQL.
выбирает identity, sequence или hilo, в зависимости от возможностей используемой базы данных.
оставляет отвественность по назначению идентификатора приложению. Предполагается, что приложение устанавливает идентификатор перед вызовом save().
используется идентификатор другого, ассоциированного объекта. Обычно используется в крньюкции с <one-to-one> оассоциацией по первичному ключу.
Генераторы hilo и seqhilo предоставляют две альтернативные реализации алгортма hi/lo, наиболее предпочтительного подхода для генерации идентификаторов. Первая реализация требует "специальной" таблицы в базе данных, для хранения следующего "hi" значения. Вторая реализация использует последовательность (Oracle-style), в базах данных, которые их поддерживают.
<id name="id" type="long" column="cat_id"> <generator class="hilo"> <param name="table">hi_value</param> <param name="column">next_value</param> <param name="max_lo">100</param> </generator> </id>
<id name="id" type="long" column="cat_id"> <generator class="seqhilo"> <param name="sequence">hi_value</param> <param name="max_lo">100</param> </generator> </id>
К сожалению вы не можете использовать hilo в случае поставки своего соединения (Connection) в Hibernate, так же невозможно его использование в конфигурации, когда Hiberante получает соединение к базе данных используя datasource через JTA. Hiberante должен иметь возможность получать "hi" значение в новой тразакции. Стандартным подходом в EJB, является использование session stateless bean для реализации алгоритма hi/lo.
The UUIDs contain: IP address, startup time of the JVM (accurate to a quarter second), system time and a counter value (unique within the JVM). It's not possible to obtain a MAC address or memory address from Java code, so this is the best we can do without using JNI.
Don't try to use uuid.string in PostgreSQL.
For databases which support identity columns (DB2, MySQL, Sybase, MS SQL), you may use identity key generation. For databases that support sequences (DB2, Oracle, PostgreSQL, Interbase, McKoi, SAP DB) you may use sequence style key generation. Both these strategies require two SQL queries to insert a new object.
<id name="id" type="long" column="uid"> <generator class="sequence"> <param name="sequence">uid_sequence</param> </generator> </id>
<id name="id" type="long" column="uid" unsaved-value="0"> <generator class="identity"/> </id>
For cross-platform development, the native strategy will choose from the identity, sequence and hilo strategies, dependant upon the capabilities of the underlying database.
If you want the application to assign identifiers (as opposed to having Hibernate generate them), you may use the assigned generator. This special generator will use the identifier value already assigned to the object's identifier property. Be very careful when using this feature to assign keys with business meaning (almost always a terrible design decision).
Due to its inherent nature, entities that use this generator cannot be saved via the Session's saveOrUpdate() method. Instead you have to explicitly specify to Hibernate if the object should be saved or updated by calling either the save() or update() method of the Session.
<composite-id name="propertyName" class="ClassName" unsaved-value="any|none" access="field|property|ClassName"> <key-property name="propertyName" type="typename" column="column_name"/> <key-many-to-one name="propertyName class="ClassName" column="column_name"/> ...... </composite-id>
For a table with a composite key, you may map multiple properties of the class as identifier properties. The <composite-id> element accepts <key-property> property mappings and <key-many-to-one> mappings as child elements.
<composite-id> <key-property name="medicareNumber"/> <key-property name="dependent"/> </composite-id>
Your persistent class must override equals() and hashCode() to implement composite identifier equality. It must also implements Serializable.
Unfortunately, this approach to composite identifiers means that a persistent object is its own identifier. There is no convenient "handle" other than the object itself. You must instantiate an instance of the persistent class itself and populate its identifier properties before you can load() the persistent state associated with a composite key. We will describe a much more convenient approach where the composite identifier is implemented as a seperate class in Раздел 7.4, «Компоненты как составные идентификаторы». The attributes described below apply only to this alternative approach:
name (optional): A property of component type that holds the composite identifier (see next section).
class (optional - defaults to the property type determined by reflection): The component class used as a composite identifier (see next section).
unsaved-value (optional - defaults to none): Indicates that transient instances should be considered newly instantiated, if set to any.
The <discriminator> element is required for polymorphic persistence using the table-per-class-hierarchy mapping strategy and declares a discriminator column of the table. The discriminator column contains marker values that tell the persistence layer what subclass to instantiate for a particular row. A restricted set of types may be used: string, character, integer, byte, short, boolean, yes_no, true_false.
<discriminator column="discriminator_column" (1) type="discriminator_type" (2) force="true|false" (3) />
(1) | column (optional - defaults to class) the name of the discriminator column. |
(2) | type (optional - defaults to string) a name that indicates the Hibernate type |
(3) | force (optional - defaults to false) "force" Hibernate to specify allowed discriminator values even when retrieving all instances of the root class. |
Actual values of the discriminator column are specified by the discriminator-value attribute of the <class> and <subclass> elements.
The force attribute is (only) useful if the table contains rows with "extra" discriminator values that are not mapped to a persistent class. This will not usually be the case.
The <version> element is optional and indicates that the table contains versioned data. This is particularly useful if you plan to use long transactions (see below).
<version column="version_column" (1) name="propertyName" (2) type="typename" (3) access="field|property|ClassName" (4) unsaved-value="null|negative|undefined" (5) />
(1) | column (optional - defaults to the property name): The name of the column holding the version number. |
(2) | name: The name of a property of the persistent class. |
(3) | type (optional - defaults to integer): The type of the version number. |
(4) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
(5) | unsaved-value (optional - defaults to undefined): A version property value that indicates that an instance is newly instantiated (unsaved), distinguishing it from transient instances that were saved or loaded in a previous session. (undefined specifies that the identifier property value should be used.) |
Version numbers may be of type long, integer, short, timestamp or calendar.
The optional <timestamp> element indicates that the table contains timestamped data. This is intended as an alternative to versioning. Timestamps are by nature a less safe implementation of optimistic locking. However, sometimes the application might use the timestamps in other ways.
<timestamp column="timestamp_column" (1) name="propertyName" (2) access="field|property|ClassName" (3) unsaved-value="null|undefined" (4) />
(1) | column (optional - defaults to the property name): The name of a column holding the timestamp. |
(2) | name: The name of a JavaBeans style property of Java type Date or Timestamp of the persistent class. |
(3) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
(4) | unsaved-value (optional - defaults to null): A version property value that indicates that an instance is newly instantiated (unsaved), distinguishing it from transient instances that were saved or loaded in a previous session. (undefined specifies that the identifier property value should be used.) |
Note that <timestamp> is equivalent to <version type="timestamp">.
The <property> element declares a persistent, JavaBean style property of the class.
<property name="propertyName" (1) column="column_name" (2) type="typename" (3) update="true|false" (4) insert="true|false" (4) formula="arbitrary SQL expression" (5) access="field|property|ClassName" (6) />
(1) | name: the name of the property, with an initial lowercase letter. |
(2) | column (optional - defaults to the property name): the name of the mapped database table column. |
(3) | type (optional): a name that indicates the Hibernate type. |
(4) | update, insert (optional - defaults to true) : specifies that the mapped columns should be included in SQL UPDATE and/or INSERT statements. Setting both to false allows a pure "derived" property whose value is initialized from some other property that maps to the same colum(s) or by a trigger or other application. |
(5) | formula (optional): an SQL expression that defines the value for a computed property. Computed properties do not have a column mapping of their own. |
(6) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
typename could be:
The name of a Hibernate basic type (eg. integer, string, character, date, timestamp, float, binary, serializable, object, blob).
The name of a Java class with a default basic type (eg. int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob).
The name of a subclass of PersistentEnum (eg. eg.Color).
The name of a serializable Java class.
The class name of a custom type (eg. com.illflow.type.MyCustomType).
If you do not specify a type, Hibernate will use reflection upon the named property to take a guess at the correct Hibernate type. Hibernate will try to interpret the name of the return class of the property getter using rules 2, 3, 4 in that order. However, this is not always enough. In certain cases you will still need the type attribute. (For example, to distinguish between Hibernate.DATE and Hibernate.TIMESTAMP, or to specify a custom type.)
The access attribute lets you control how Hibernate will access the property at runtime. By default, Hibernate will call the property get/set pair. If you specify access="field", Hibernate will bypass the get/set pair and access the field directly, using reflection. You may specify your own strategy for property access by naming a class that implements the interface net.sf.hibernate.property.PropertyAccessor.
An ordinary association to another persistent class is declared using a many-to-one element. The relational model is a many-to-one association. (Its really just an object reference.)
<many-to-one name="propertyName" (1) column="column_name" (2) class="ClassName" (3) cascade="all|none|save-update|delete" (4) outer-join="true|false|auto" (5) update="true|false" (6) insert="true|false" (6) property-ref="propertyNameFromAssociatedClass" (7) access="field|property|ClassName" (8) />
(1) | name: The name of the property. |
(2) | column (optional): The name of the column. |
(3) | class (optional - defaults to the property type determined by reflection): The name of the associated class. |
(4) | cascade (optional): Specifies which operations should be cascaded from the parent object to the associated object. |
(5) | outer-join (optional - defaults to auto): enables outer-join fetching for this association when hibernate.use_outer_join is set. |
(6) | update, insert (optional - defaults to true) specifies that the mapped columns should be included in SQL UPDATE and/or INSERT statements. Setting both to false allows a pure "derived" association whose value is initialized from some other property that maps to the same colum(s) or by a trigger or other application. |
(7) | property-ref: (optional) The name of a property of the associated class that is joined to this foreign key. If not specified, the primary key of the associated class is used. |
(8) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
The cascade attribute permits the following values: all, save-update, delete, none. Setting a value other than none will propagate certain operations to the associated (child) object. See "Lifecycle Objects" below.
The outer-join attribute accepts three different values:
auto (default) Fetch the association using an outerjoin if the associated class has no proxy
true Always fetch the association using an outerjoin
false Never fetch the association using an outerjoin
A typical many-to-one declaration looks as simple as
<many-to-one name="product" class="Product" column="PRODUCT_ID"/>
The property-ref attribute should only be used for mapping legacy data where a foreign key refers to a unique key of the associated table other than the primary key. This is an ugly relational model. For example, suppose the Product class had a unique serial number, that is not the primary key. (The unique attribute controls Hibernate's DDL generation with the SchemaExport tool.)
<property name="serialNumber" unique="true" type="string" column="SERIAL_NUMBER"/>
Then the mapping for OrderItem might use:
<many-to-one name="product" property-ref="serialNumber" column="PRODUCT_SERIAL_NUMBER"/>
This is certainly not encouraged, however.
A one-to-one association to another persistent class is declared using a one-to-one element.
<one-to-one name="propertyName" (1) class="ClassName" (2) cascade="all|none|save-update|delete" (3) constrained="true|false" (4) outer-join="true|false|auto" (5) property-ref="propertyNameFromAssociatedClass" (6) access="field|property|ClassName" (7) />
(1) | name: The name of the property. |
(2) | class (optional - defaults to the property type determined by reflection): The name of the associated class. |
(3) | cascade (optional) specifies which operations should be cascaded from the parent object to the associated object. |
(4) | constrained (optional) specifies that a foreign key constraint on the primary key of the mapped table references the table of the associated class. This option affects the order in which save() and delete() are cascaded (and is also used by the schema export tool). |
(5) | outer-join (optional - defaults to auto): Enable outer-join fetching for this association when hibernate.use_outer_join is set. |
(6) | property-ref: (optional) The name of a property of the associated class that is joined to the primary key of this class. If not specified, the primary key of the associated class is used. |
(7) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
There are two varieties of one-to-one association:
primary key associations
unique foreign key associations
Primary key associations don't need an extra table column; if two rows are related by the association then the two table rows share the same primary key value. So if you want two objects to be related by a primary key association, you must make sure that they are assigned the same identifier value!
For a primary key association, add the following mappings to Employee and Person, respectively.
<one-to-one name="person" class="Person"/>
<one-to-one name="employee" class="Employee" constrained="true"/>
Now we must ensure that the primary keys of related rows in the PERSON and EMPLOYEE tables are equal. We use a special Hibernate identifier generation strategy called foreign:
<class name="person" table="PERSON"> <id name="id" column="PERSON_ID"> <generator class="foreign"> <param name="property">employee</param> </generator> </id> ... <one-to-one name="employee" class="Employee" constrained="true"/> </class>
A newly saved instance of Person is then assigned the same primar key value as the Employee instance refered with the employee property of that Person.
Alternatively, a foreign key with a unique constraint, from Employee to Person, may be expressed as:
<many-to-one name="person" class="Person" column="PERSON_ID" unique="true"/>
And this association may be made bidirectional by adding the following to the Person mapping:
<one-to-one name"employee" class="Employee" property-ref="person"/>
The <component> element maps properties of a child object to columns of the table of a parent class. Components may, in turn, declare their own properties, components or collections. See "Components" below.
<component name="propertyName" (1) class="className" (2) insert="true|false" (3) upate="true|false" (4) access="field|property|ClassName"> (5) <property ...../> <many-to-one .... /> ........ </component>
(1) | name: The name of the property. |
(2) | class (optional - defaults to the property type determined by reflection): The name of the component (child) class. |
(3) | insert: Do the mapped columns appear in SQL INSERTs? |
(4) | update: Do the mapped columns appear in SQL UPDATEs? |
(5) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
The child <property> tags map properties of the child class to table columns.
The <component> element allows a <parent> subelement that maps a property of the component class as a reference back to the containing entity.
The <dynamic-component> element allows a Map to be mapped as a component, where the property names refer to keys of the map.
Finally, polymorphic persistence requires the declaration of each subclass of the root persistent class. For the (recommended) table-per-class-hierarchy mapping strategy, the <subclass> declaration is used.
<subclass name="ClassName" (1) discriminator-value="discriminator_value" (2) proxy="ProxyInterface" (3) lazy="true|false" (4) dynamic-update="true|false" dynamic-insert="true|false"> <property .... /> ..... </subclass>
(1) | name: The fully qualified class name of the subclass. |
(2) | discriminator-value (optional - defaults to the class name): A value that distiguishes individual subclasses. |
(3) | proxy (optional): Specifies a class or interface to use for lazy initializing proxies. |
(4) | lazy (optional): Setting lazy="true" is a shortcut equalivalent to specifying the name of the class itself as the proxy interface. |
Each subclass should declare its own persistent properties and subclasses. <version> and <id> properties are assumed to be inherited from the root class. Each subclass in a heirarchy must define a unique discriminator-value. If none is specified, the fully qualified Java class name is used.
Alternatively, a subclass that is persisted to its own table (table-per-subclass mapping strategy) is declared using a <joined-subclass> element.
<joined-subclass name="ClassName" (1) proxy="ProxyInterface" (2) lazy="true|false" (3) dynamic-update="true|false" dynamic-insert="true|false"> <key .... > <property .... /> ..... </joined-subclass>
(1) | name: The fully qualified class name of the subclass. |
(2) | proxy (optional): Specifies a class or interface to use for lazy initializing proxies. |
(3) | lazy (optional): Setting lazy="true" is a shortcut equalivalent to specifying the name of the class itself as the proxy interface. |
No discriminator column is required for this mapping strategy. Each subclass must, however, declare a table column holding the object identifier using the <key> element. The mapping at the start of the chapter would be re-written as:
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <hibernate-mapping package="eg"> <class name="Cat" table="CATS"> <id name="id" column="uid" type="long"> <generator class="hilo"/> </id> <property name="birthdate" type="date"/> <property name="color" not-null="true"/> <property name="sex" not-null="true"/> <property name="weight"/> <many-to-one name="mate"/> <set name="kittens"> <key column="MOTHER"/> <one-to-many class="Cat"/> </set> <joined-subclass name="DomesticCat" table="DOMESTIC_CATS"> <key column="CAT"/> <property name="name" type="string"/> </joined-subclass> </class> <class name="eg.Dog"> <!-- mapping for Dog could go here --> </class> </hibernate-mapping>
Suppose your application has two persistent classes with the same name, and you don't want to specify the fully qualified (package) name in Hibernate queries. Classes may be "imported" explicitly, rather than relying upon auto-import="true". You may even import classes and interfaces that are not explicitly mapped.
<import class="java.lang.Object" rename="Universe"/>
<import class="ClassName" (1) rename="ShortName" (2) />
(1) | class: The fully qualified class name of of any Java class. |
(2) | rename (optional - defaults to the unqualified class name): A name that may be used in the query language. |
To understand the behaviour of various Java language-level objects with respect to the persistence service, we need to classify them into two groups:
An entity exists independently of any other objects holding references to the entity. Contrast this with the usual Java model where an unreferenced object is garbage collected. Entities must be explicitly saved and deleted (except that saves and deletions may be cascaded from a parent entity to its children). This is different from the ODMG model of object persistence by reachablity - and corresponds more closely to how application objects are usually used in large systems. Entities support circular and shared references. They may also be versioned.
An entity's persistent state consists of references to other entities and instances of value types. Values are primitives, collections, components and certain immutable objects. Unlike entities, values (in particular collections and components) are persisted and deleted by reachability. Since value objects (and primitives) are persisted and deleted along with their containing entity they may not be independently versioned. Values have no independent identity, so they cannot be shared by two entities or collections.
All Hibernate types except collections support null semantics.
Up until now, we've been using the term "persistent class" to refer to entities. We will continue to do that. Strictly speaking, however, not all user-defined classes with persistent state are entities. A component is a user defined class with value semantics.
The basic types may be roughly categorized into
Type mappings from Java primitives or wrapper classes to appropriate (vendor-specific) SQL column types. boolean, yes_no and true_false are all alternative encodings for a Java boolean or java.lang.Boolean.
A type mapping from java.lang.String to VARCHAR (or Oracle VARCHAR2).
Type mappings from java.util.Date and its subclasses to SQL types DATE, TIME and TIMESTAMP (or equivalent).
Type mappings from java.util.Calendar to SQL types TIMESTAMP and DATE (or equivalent).
A type mapping from java.math.BigDecimal to NUMERIC (or Oracle NUMBER).
Type mappings from java.util.Locale, java.util.TimeZone and java.util.Currency to VARCHAR (or Oracle VARCHAR2). Instances of Locale and Currency are mapped to their ISO codes. Instances of TimeZone are mapped to their ID.
A type mapping from java.lang.Class to VARCHAR (or Oracle VARCHAR2). A Class is mapped to its fully qualified name.
Maps byte arrays to an appropriate SQL binary type.
Maps long Java strings to a SQL CLOB or TEXT type.
Maps serializable Java types to an appropriate SQL binary type. You may also indicate the Hibernate type serializable with the name of a serializable Java class or interface that does not default to a basic type or implement PersistentEnum.
Type mappings for the JDBC classes java.sql.Clob and java.sql.Blob. These types may be inconvenient for some applications, since the blob or clob object may not be reused outside of a transaction. (Furthermore, driver support is patchy and inconsistent.)
Unique identifiers of entities and collections may be of any basic type except binary, blob and clob. (Composite identifiers are also allowed, see below.)
The basic value types have corresponding Type constants defined on net.sf.hibernate.Hibernate. For example, Hibernate.STRING represents the string type.
An enumerated type is a common Java idiom where a class has a constant (small) number of immutable instances. You may create a persistent enumerated type by implementing net.sf.hibernate.PersistentEnum, defining the operations toInt() and fromInt():
package eg; import net.sf.hibernate.PersistentEnum; public class Color implements PersistentEnum { private final int code; private Color(int code) { this.code = code; } public static final Color TABBY = new Color(0); public static final Color GINGER = new Color(1); public static final Color BLACK = new Color(2); public int toInt() { return code; } public static Color fromInt(int code) { switch (code) { case 0: return TABBY; case 1: return GINGER; case 2: return BLACK; default: throw new RuntimeException("Unknown color code"); } } }
The Hibernate type name is simply the name of the enumerated class, in this case eg.Color.
It is relatively easy for developers to create their own value types. For example, you might want to persist properties of type java.lang.BigInteger to VARCHAR columns. Hibernate does not provide a built-in type for this. But custom types are not limited to mapping a property (or collection element) to a single table column. So, for example, you might have a Java property getName()/setName() of type java.lang.String that is persisted to the columns FIRST_NAME, INITIAL, SURNAME.
To implement a custom type, implement either net.sf.hibernate.UserType or net.sf.hibernate.CompositeUserType and declare properties using the fully qualified classname of the type. Check out net.sf.hibernate.test.DoubleStringType to see the kind of things that are possible.
<property name="twoStrings" type="net.sf.hibernate.test.DoubleStringType"> <column name="first_string"/> <column name="second_string"/> </property>
Notice the use of <column> tags to map a property to multiple columns.
Even though Hibernate's rich range of built-in types and support for components means you will very rarely need to use a custom type, it is nevertheless considered good form to use custom types for (non-entity) classes that occur frequently in your application. For example, a MonetoryAmount class is a good candidate for a CompositeUserType, even though it could easily be mapped as a component. One motivation for this is abstraction. With a custom type, your mapping documents would be future-proofed against possible changes in your way of representing monetory values.
There is one further type of property mapping. The <any> mapping element defines a polymorphic association to classes from multiple tables. This type of mapping always requires more than one column. The first column holds the type of the associated entity. The remaining columns hold the identifier. It is impossible to specify a foreign key constraint for this kind of association, so this is most certainly not meant as the usual way of mapping (polymorphic) associations. You should use this only in very special cases (eg. audit logs, user session data, etc).
<any name="anyEntity" id-type="long" meta-type="eg.custom.Class2TablenameType"> <column name="table_name"/> <column name="id"/> </any>
The meta-type attribute lets the application specify a custom type that maps database column values to persistent classes which have identifier properties of the type specified by id-type. If the meta-type returns instances of java.lang.Class, nothing else is required. On the other hand, if it is a basic type like string or character, you must specify the mapping from values to classes.
<any name="anyEntity" id-type="long" meta-type="string"> <meta-value value="TBL_ANIMAL" class="Animal"/> <meta-value value="TBL_HUMAN" class="Human"/> <meta-value value="TBL_ALIEN" class="Alien"/> <column name="table_name"/> <column name="id"/> </any>
<any name="propertyName" (1) id-type="idtypename" (2) meta-type="metatypename" (3) cascade="none|all|save-update" (4) access="field|property|ClassName" (5) > <meta-value ... /> <meta-value ... /> ..... <column .... /> <column .... /> ..... </any>
(1) | name: the property name. |
(2) | id-type: the identifier type. |
(3) | meta-type (optional - defaults to class): a type that maps java.lang.Class to a single database column or, alternatively, a type that is allowed for a discriminator mapping. |
(4) | cascade (optional- defaults to none): the cascade style. |
(5) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
The old object type that filled a similar role in Hibernate 1.2 is still supported, but is now semi-deprecated.
You may force Hibernate to quote an identifier in the generated SQL by enclosing the table or column name in backticks in the mapping document. Hibernate will use the correct quotation style for the SQL Dialect (usually double quotes, but brackets for SQL Server and backticks for MySQL).
<class name="LineItem" table="`Line Item`"> <id name="id" column="`Item Id`"/><generator class="assigned"/></id> <property name="itemNumber" column="`Item #`"/> ... </class>
It is possible to define subclass and joined-subclass mappings in seperate mapping documents, directly beneath hibernate-mapping. This allows you to extend a class hierachy just by adding a new mapping file. You must specify an extends attribute in the subclass mapping, naming a previously mapped superclass. Use of this feature makes the ordering of the mapping documents important!
<hibernate-mapping> <subclass name="eg.subclass.DomesticCat" extends="eg.Cat" discriminator-value="D"> <property name="name" type="string"/> </subclass> </hibernate-mapping>
This section does not contain much example Java code. We assume you already know how to use Java's collections framework. If so, there's not really anything more to know - with a single caveat, you may use Java collections the same way you always have.
Hibernate can persist instances of java.util.Map, java.util.Set, java.util.SortedMap, java.util.SortedSet, java.util.List, and any array of persistent entities or values. Properties of type java.util.Collection or java.util.List may also be persisted with "bag" semantics.
Now the caveat: persistent collections do not retain any extra semantics added by the class implementing the collection interface (eg. iteration order of a LinkedHashSet). The persistent collections actually behave like HashMap, HashSet, TreeMap, TreeSet and ArrayList respectively. Furthermore, the Java type of a property holding a collection must be the interface type (ie. Map, Set or List; never HashMap, TreeSet or ArrayList). This restriction exists because, when you're not looking, Hibernate sneakily replaces your instances of Map, Set and List with instances of its own persistent implementations of Map, Set or List. (So also be careful when using == on your collections.)
Cat cat = new DomesticCat(); Cat kitten = new DomesticCat(); .... Set kittens = new HashSet(); kittens.add(kitten); cat.setKittens(kittens); session.save(cat); kittens = cat.getKittens(); //Okay, kittens collection is a Set (HashSet) cat.getKittens(); //Error!
Collections obey the usual rules for value types: no shared references, created and deleted along with containing entity. Due to the underlying relational model, they do not support null value semantics; Hibernate does not distinguish between a null collection reference and an empty collection.
Collections are automatically persisted when referenced by a persistent object and automatically deleted when unreferenced. If a collection is passed from one persistent object to another, its elements might be moved from one table to another. You shouldn't have to worry much about any of this. Just use Hibernate's collections the same way you use ordinary Java collections, but make sure you understand the semantics of bidirectional associations (discussed later) before using them.
Collection instances are distinguished in the database by a foreign key to the owning entity. This foreign key is referred to as the collection key . The collection key is mapped by the <key> element.
Collections may contain almost any other Hibernate type, including all basic types, custom types, entity types and components. This is an important definition: An object in a collection can either be handled with "pass by value" semantics (it therefore fully depends on the collection owner) or it can be a reference to another entity with an own lifecycle. Collections may not contain other collections. The contained type is referred to as the collection element type. Collection elements are mapped by <element>, <composite-element>, <one-to-many>, <many-to-many> or <many-to-any>. The first two map elements with value semantics, the other three are used to map entity associations.
All collection types except Set and bag have an index column - a column that maps to an array or List index or Map key. The index of a Map may be of any basic type, an entity type or even a composite type (it may not be a collection). The index of an array or list is always of type integer. Indexes are mapped using <index>, <index-many-to-many>, <composite-index> or <index-many-to-any>.
There are quite a range of mappings that can be generated for collections, covering many common relational models. We suggest you experiment with the schema generation tool to get a feeling for how various mapping declarations translate to database tables.
Collections are declared by the <set>, <list>, <map>, <bag>, <array> and <primitive-array> elements. <map> is representative:
<map name="propertyName" (1) table="table_name" (2) schema="schema_name" (3) lazy="true|false" (4) inverse="true|false" (5) cascade="all|none|save-update|delete|all-delete-orphan" (6) sort="unsorted|natural|comparatorClass" (7) order-by="column_name asc|desc" (8) where="arbitrary sql where condition" (9) outer-join="true|false|auto" (10) batch-size="N" (11) access="field|property|ClassName" (12) > <key .... /> <index .... /> <element .... /> </map>
(1) | name the collection property name |
(2) | table (optional - defaults to property name) the name of the collection table (not used for one-to-many associations) |
(3) | schema (optional) the name of a table schema to override the schema declared on the root element |
(4) | lazy (optional - defaults to false) enable lazy initialization (not used for arrays) |
(5) | inverse (optional - defaults to false) mark this collection as the "inverse" end of a bidirectional association |
(6) | cascade (optional - defaults to none) enable operations to cascade to child entities |
(7) | sort (optional) specify a sorted collection with natural sort order, or a given comparator class |
(8) | order-by (optional, JDK1.4 only) specify a table column (or columns) that define the iteration order of the Map, Set or bag, together with an optional asc or desc |
(9) | where (optional) specify an arbitrary SQL WHERE condition to be used when retrieving or removing the collection (useful if the collection should contain only a subset of the available data) |
(10) | outer-join (optional) specify that the collection should be fetched by outer join, whenever possible. Only one collection may be fetched by outer join per SQL SELECT. |
(11) | batch-size (optional, defaults to 1) specify a "batch size" for lazily fetching instances of this collection. |
(12) | access (optional - defaults to property): The strategy Hibernate should use for accessing the property value. |
The mapping of a List or array requires a seperate table column holding the array or list index (the i in foo[i]). If your relational model doesn't have an index column, e.g. if you're working with legacy data, use an unordered Set instead. This seems to put people off who assume that List should just be a more convenient way of accessing an unordered collection. Hibernate collections strictly obey the actual semantics attached to the Set, List and Map interfaces. List elements don't just spontaneously rearrange themselves!
On the other hand, people who planned to use the List to emulate bag semantics have a legitimate grievance here. A bag is an unordered, unindexed collection which may contain the same element multiple times. The Java collections framework lacks a Bag interface, hence you have to emulate it with a List. Hibernate lets you map properties of type List or Collection with the <bag> element. Note that bag semantics are not really part of the Collection contract and they actually conflict with the semantics of the List contract (however, you can sort the bag arbitrarily, discussed later in this chapter).
Note: Large Hibernate bags mapped with inverse="false" are inefficient and should be avoided; Hibernate can't create, delete or update rows individually, because there is no key that may be used to identify an individual row.
A collection table is required for any collection of values and any collection of references to other entities mapped as a many-to-many association (the natural semantics for a Java collection). The table requires (foreign) key column(s), element column(s) and possibly index column(s).
The foreign key from the collection table to the table of the owning class is declared using a <key> element.
<key column="column_name"/>
(1) | column (required): The name of the foreign key column. |
For indexed collections like maps and lists, we require an <index> element. For lists, this column contains sequential integers numbered from zero. Make sure that your index really starts from zero if you have to deal with legacy data. For maps, the column may contain any values of any Hibernate type.
<index column="column_name" (1) type="typename" (2) />
(1) | column (required): The name of the column holding the collection index values. |
(2) | type (optional, defaults to integer): The type of the collection index. |
Alternatively, a map may be indexed by objects of entity type. We use the <index-many-to-many> element.
<index-many-to-many column="column_name" (1) class="ClassName" (2) />
(1) | column (required): The name of the foreign key column for the collection index values. |
(2) | class (required): The entity class used as the collection index. |
For a collection of values, we use the <element> tag.
<element column="column_name" (1) type="typename" (2) />
(1) | column (required): The name of the column holding the collection element values. |
(2) | type (required): The type of the collection element. |
A collection of entities with its own table corresponds to the relational notion of many-to-many association. A many to many association is the most natural mapping of a Java collection but is not usually the best relational model.
<many-to-many column="column_name" (1) class="ClassName" (2) outer-join="true|false|auto" (3) />
(1) | column (required): The name of the element foreign key column. |
(2) | class (required): The name of the associated class. |
(3) | outer-join (optional - defaults to auto): enables outer-join fetching for this association when hibernate.use_outer_join is set. |
Some examples, first, a set of strings:
<set name="names" table="NAMES"> <key column="GROUPID"/> <element column="NAME" type="string"/> </set>
A bag containing integers (with an iteration order determined by the order-by attribute):
<bag name="sizes" table="SIZES" order-by="SIZE ASC"> <key column="OWNER"/> <element column="SIZE" type="integer"/> </bag>
An array of entities - in this case, a many to many association (note that the entities are lifecycle objects, cascade="all"):
<array name="foos" table="BAR_FOOS" cascade="all"> <key column="BAR_ID"/> <index column="I"/> <many-to-many column="FOO_ID" class="org.hibernate.Foo"/> </array>
A map from string indices to dates:
<map name="holidays" table="holidays" schema="dbo" order-by="hol_name asc"> <key column="id"/> <index column="hol_name" type="string"/> <element column="hol_date" type="date"/> </map>
A list of components (discussed in the next chapter):
<list name="carComponents" table="car_components"> <key column="car_id"/> <index column="posn"/> <composite-element class="org.hibernate.car.CarComponent"> <property name="price" type="float"/> <property name="type" type="org.hibernate.car.ComponentType"/> <property name="serialNumber" column="serial_no" type="string"/> </composite-element> </list>
A one to many association links the tables of two classes directly, with no intervening collection table. (This implements a one-to-many relational model.) This relational model loses some of the semantics of Java collections:
No null values may be contained in a map, set or list
An instance of the contained entity class may not belong to more than one instance of the collection
An instance of the contained entity class may not appear at more than one value of the collection index
An association from Foo to Bar requires the addition of a key column and possibly an index column to the table of the contained entity class, Bar. These columns are mapped using the <key> and <index> elements described above.
The <one-to-many> tag indicates a one to many association.
<one-to-many class="ClassName"/>
(1) | class (required): The name of the associated class. |
Example:
<set name="bars"> <key column="foo_id"/> <one-to-many class="org.hibernate.Bar"/> </set>
Notice that the <one-to-many> element does not need to declare any columns. Nor is it necessary to specify the table name anywhere.
Very Important Note: If the <key> column of a <one-to-many> association is declared NOT NULL, Hibernate may cause constraint violations when it creates or updates the association. To prevent this problem, you must use a bidirectional association with the many valued end (the set or bag) marked as inverse="true". See the discussion of bidirectional associations later in this chapter.
Collections (other than arrays) may be lazily initialized, meaning they load their state from the database only when the application needs to access it. Initialization happens transparently to the user so the application would not normally need to worry about this (in fact, transparent lazy initialization is the main reason why Hibernate needs its own collection implementations). However, if the application tries something like this:
s = sessions.openSession(); User u = (User) s.find("from User u where u.name=?", userName, Hibernate.STRING).get(0); Map permissions = u.getPermissions(); s.connection().commit(); s.close(); Integer accessLevel = (Integer) permissions.get("accounts"); // Error!
It could be in for a nasty surprise. Since the permissions collection was not initialized when the Session was committed, the collection will never be able to load its state. The fix is to move the line that reads from the collection to just before the commit. (There are other more advanced ways to solve this problem, however.)
Alternatively, use a non-lazy collection. Since lazy initialization can lead to bugs like that above, non-laziness is the default. However, it is intended that lazy initialization be used for almost all collections, especially for collections of entities (for reasons of efficiency).
Exceptions that occur while lazily initializing a collection are wrapped in a LazyInitializationException.
Declare a lazy collection using the optional lazy attribute:
<set name="names" table="NAMES" lazy="true"> <key column="group_id"/> <element column="NAME" type="string"/> </set>
In some application architectures, particularly where the code that accesses data using Hibernate, and the code that uses it are in different application layers, it can be a problem to ensure that the Session is open when a collection is initialized. They are two basic ways to deal with this issue:
In a web-based application, a servlet filter can be used to close the Session only at the very end of a user request, once the rendering of the view is complete. Of course, this places heavy demands upon the correctness of the exception handling of your application infrastructure. It is vitally important that the Session is closed and the transaction ended before returning to the user, even when an exception occurs during rendering of the view. The servlet filter has to be able to access the Session for this approach. We recommend that a ThreadLocal variable be used to hold the current Session (see chapter 1, Раздел 1.4, «Поиграем с котами», for an example implementation).
In an application with a seperate business tier, the business logic must "prepare" all collections that will be needed by the web tier before returning. This means that the business tier should load all the data and return all the data already initialized to the presentation/web tier that is required for a particular use case. Usually, the application calls Hibernate.initialize() for each collection that will be needed in the web tier (this call must occur before the session is closed) or retrieves the collection eagerly using a Hibernate query with a FETCH clause.
You may also attach a previously loaded object to a new Session with update() or lock() before accessing unitialized collections (or other proxies). Hibernate can not do this automatically, as it would introduce ad hoc transaction semantics!
You can use the filter() method of the Hibernate Session API to get the size of a collection without initializing it:
( (Integer) s.filter( collection, "select count(*)" ).get(0) ).intValue()
filter() or createFilter() are also used to efficiently retrieve subsets of a collection without needing to initialize the whole collection.
Hibernate supports collections implementing java.util.SortedMap and java.util.SortedSet. You must specify a comparator in the mapping file:
<set name="aliases" table="person_aliases" sort="natural"> <key column="person"/> <element column="name" type="string"/> </set> <map name="holidays" sort="my.custom.HolidayComparator" lazy="true"> <key column="year_id"/> <index column="hol_name" type="string"/> <element column="hol_date" type="date"/> </map>
Allowed values of the sort attribute are unsorted, natural and the name of a class implementing java.util.Comparator.
Sorted collections actually behave like java.util.TreeSet or java.util.TreeMap.
If you want the database itself to order the collection elements use the order-by attribute of set, bag or map mappings. This solution is only available under JDK 1.4 or higher (it is implemented using LinkedHashSet or LinkedHashMap). This performs the ordering in the SQL query, not in memory.
<set name="aliases" table="person_aliases" order-by="name asc"> <key column="person"/> <element column="name" type="string"/> </set> <map name="holidays" order-by="hol_date, hol_name" lazy="true"> <key column="year_id"/> <index column="hol_name" type="string"/> <element column="hol_date type="date"/> </map>
Note that the value of the order-by attribute is an SQL ordering, not a HQL ordering!
Associations may even be sorted by some arbitrary criteria at runtime using a filter().
sortedUsers = s.filter( group.getUsers(), "order by this.name" );
If you've fully embraced our view that composite keys are a bad thing and that entities should have synthetic identifiers (surrogate keys), then you might find it a bit odd that the many to many associations and collections of values that we've shown so far all map to tables with composite keys! Now, this point is quite arguable; a pure association table doesn't seem to benefit much from a surrogate key (though a collection of composite values might). Nevertheless, Hibernate provides a (slightly experimental) feature that allows you to map many to many associations and collections of values to a table with a surrogate key.
The <idbag> element lets you map a List (or Collection) with bag semantics.
<idbag name="lovers" table="LOVERS" lazy="true"> <collection-id column="ID" type="long"> <generator class="hilo"/> </collection-id> <key column="PERSON1"/> <many-to-many column="PERSON2" class="eg.Person" outer-join="true"/> </idbag>
As you can see, an <idbag> has a synthetic id generator, just like an entity class! A different surrogate key is assigned to each collection row. Hibernate does not provide any mechanism to discover the surrogate key value of a particular row, however.
Note that the update performance of an <idbag> is much better than a regular <bag>! Hibernate can locate individual rows efficiently and update or delete them individually, just like a list, map or set.
In the current implementation, the identity identifier generation strategy is not supported for <idbag> collection identifiers.
A bidirectional association allows navigation from both "ends" of the association. Two kinds of bidirectional association are supported:
set or bag valued at one end, single-valued at the other
set or bag valued at both ends
Please note that Hibernate does not support bidirectional one-to-many associations with an indexed collection (list, map or array) as the "many" end, you have to use a set or bag mapping.
You may specify a bidirectional many-to-many association simply by mapping two many-to-many associations to the same database table and declaring one end as inverse (which one is your choice). Here's an example of a bidirectional many-to-many association from a class back to itself (each category can have many items and each item can be in many categories):
<class name="org.hibernate.auction.Category"> <id name="id" column="ID"/> ... <bag name="items" table="CATEGORY_ITEM" lazy="true"> <key column="CATEGORY_ID"/> <many-to-many class="org.hibernate.auction.Item" column="ITEM_ID"/> </bag> </class> <class name="org.hibernate.auction.Item"> <id name="id" column="ID"/> ... <!-- inverse end --> <bag name="categories" table="CATEGORY_ITEM" inverse="true" lazy="true"> <key column="ITEM_ID"/> <many-to-many class="org.hibernate.auction.Category" column="CATEGORY_ID"/> </bag> </class>
Changes made only to the inverse end of the association are not persisted. This means that Hibernate has two representations in memory for every bidirectional association, one link from A to B and another link from B to A. This is easier to understand if you think about the Java object model and how we create a many-to-many relationship in Java:
category.getItems().add(item); // The category now "knows" about the relationship item.getCategories().add(category); // The item now "knows" about the relationship session.update(item); // No effect, nothing will be saved! session.update(category); // The relationship will be saved
The non-inverse side is used to save the in-memory representation to the database. We would get an unneccessary INSERT/UPDATE and probably even a foreign key violation if both would trigger changes! The same is of course also true for bidirectional one-to-many associations.
You may map a bidirectional one-to-many association by mapping a one-to-many association to the same table column(s) as a many-to-one association and declaring the many-valued end inverse="true".
<class name="eg.Parent"> <id name="id" column="id"/> .... <set name="children" inverse="true" lazy="true"> <key column="parent_id"/> <one-to-many class="eg.Child"/> </set> </class> <class name="eg.Child"> <id name="id" column="id"/> .... <many-to-one name="parent" class="eg.Parent" column="parent_id"/> </class>
Mapping one end of an association with inverse="true" doesn't affect the operation of cascades, both are different concepts!
There are two possible approaches to mapping a ternary association. One approach is to use composite elements (discussed below). Another is to use a Map with an association as its index:
<map name="contracts" lazy="true"> <key column="employer_id"/> <index-many-to-many column="employee_id" class="Employee"/> <one-to-many class="Contract"/> </map>
<map name="connections" lazy="true"> <key column="node1_id"/> <index-many-to-many column="node2_id" class="Node"/> <many-to-many column="connection_id" class="Connection"/> </map>
The <many-to-any> and <index-many-to-any> elements provide for true heterogeneous associations. These mapping elements work in the same way as the <any> element - and should also be used rarely, if ever.
The previous sections are pretty confusing. So lets look at an example. This class:
package eg; import java.util.Set; public class Parent { private long id; private Set children; public long getId() { return id; } private void setId(long id) { this.id=id; } private Set getChildren() { return children; } private void setChildren(Set children) { this.children=children; } .... .... }
has a collection of eg.Child instances. If each child has at most one parent, the most natural mapping is a one-to-many association:
<hibernate-mapping> <class name="eg.Parent"> <id name="id"> <generator class="sequence"/> </id> <set name="children" lazy="true"> <key column="parent_id"/> <one-to-many class="eg.Child"/> </set> </class> <class name="eg.Child"> <id name="id"> <generator class="sequence"/> </id> <property name="name"/> </class> </hibernate-mapping>
This maps to the following table definitions:
create table parent ( id bigint not null primary key ) create table child ( id bigint not null primary key, name varchar(255), parent_id bigint ) alter table child add constraint childfk0 (parent_id) references parent
If the parent is required, use a bidirectional one-to-many association:
<hibernate-mapping> <class name="eg.Parent"> <id name="id"> <generator class="sequence"/> </id> <set name="children" inverse="true" lazy="true"> <key column="parent_id"/> <one-to-many class="eg.Child"/> </set> </class> <class name="eg.Child"> <id name="id"> <generator class="sequence"/> </id> <property name="name"/> <many-to-one name="parent" class="eg.Parent" column="parent_id" not-null="true"/> </class> </hibernate-mapping>
Notice the NOT NULL constraint:
create table parent ( id bigint not null primary key ) create table child ( id bigint not null primary key, name varchar(255), parent_id bigint not null ) alter table child add constraint childfk0 (parent_id) references parent
On the other hand, if a child might have multiple parents, a many-to-many association is appropriate:
<hibernate-mapping> <class name="eg.Parent"> <id name="id"> <generator class="sequence"/> </id> <set name="children" lazy="true" table="childset"> <key column="parent_id"/> <many-to-many class="eg.Child" column="child_id"/> </set> </class> <class name="eg.Child"> <id name="id"> <generator class="sequence"/> </id> <property name="name"/> </class> </hibernate-mapping>
Table definitions:
create table parent ( id bigint not null primary key ) create table child ( id bigint not null primary key, name varchar(255) ) create table childset ( parent_id bigint not null, child_id bigint not null, primary key ( parent_id, child_id ) ) alter table childset add constraint childsetfk0 (parent_id) references parent alter table childset add constraint childsetfk1 (child_id) references child
В Hibernate понятие компонент используется в нескольких различных контекстах, для разных целей.
Компонент это содержащийся объект, который сохраняется как значение, а не как сущность. Термин компонент относится к объектно-ориентированному понятию композиция (не путать с архитектурным компонентом). Например, сущность человек можно смоделировать так:
public class Person { private java.util.Date birthday; private Name name; private String key; public String getKey() { return key; } private void setKey(String key) { this.key=key; } public java.util.Date getBirthday() { return birthday; } public void setBirthday(java.util.Date birthday) { this.birthday = birthday; } public Name getName() { return name; } public void setName(Name name) { this.name = name; } ...... ...... }
public class Name { char initial; String first; String last; public String getFirst() { return first; } void setFirst(String first) { this.first = first; } public String getLast() { return last; } void setLast(String last) { this.last = last; } public char getInitial() { return initial; } void setInitial(char initial) { this.initial = initial; } }
Теперь Name, может быть сохранен как компонент сущности Person. Обратите внимание, что компонент Name определяет пары getter / setter для сохраняемых свойств, при этом не нужно определять дополнительные интерфейсы или свойства-идентификаторы.
Наш Hibernate маппинг будет выглядеть так:
<class name="eg.Person" table="person"> <id name="Key" column="pid" type="string"> <generator class="uuid.hex"/> </id> <property name="birthday" type="date"/> <component name="Name" class="eg.Name"> <!-- атрибут "class" необязателен --> <property name="initial"/> <property name="first"/> <property name="last"/> </component> </class>
Таблица сущности человек будет иметь колонки pid, birthday, initial, first и last.
Так как компоненты являются композицией, они не поддерживают совстместно используемых ссылок. Иными словами экземпляр компонента всегда один для содержащего его экзепляра класса. Не бывает ситуации когда два разных экземпляра содержат ссылку на один и тот же экземпляр компонента. Значение null является специальным для компонента. Когда подгружается содержащийся объект, Hibernate предполагает, что если все колонки компонента отсутствуют (null), то компонент также отсутствует (null). Для большинства случаев, это так и есть.
Свойства компонента могут быть любого из типов Hibernate (коллекции, ассоциации многие к одному (many-to-one), другие компоненты, и т.д.). Причём, вложенные компоненты не считаются экзотическим случаем. Hibernate предназначен для поддержки очень детализированной объектной модели.
Элемент <component> допускает подэлемент <parent>, который отображается на свойства класса компонента и ссылается на содержащую сущность.
<class name="eg.Person" table="person"> <id name="Key" column="pid" type="string"> <generator class="uuid.hex"/> </id> <property name="birthday" type="date"/> <component name="Name" class="eg.Name"> <parent name="namedPerson"/> <!-- обратная ссылка на Person --> <property name="initial"/> <property name="first"/> <property name="last"/> </component> </class>
Поддерживаются коллекции компонентов (т.е. массив Name). Объявляйте коллекции компонентов заменой тэга <element> на <composite-element>.
<set name="someNames" table="some_names" lazy="true"> <key column="id"/> <composite-element class="eg.Name"> <!-- атрибут "class" обязателен --> <property name="initial"/> <property name="first"/> <property name="last"/> </composite-element> </set>
Примечание: если вы определяете Set составных элементов, очень важно правильно реализовать equals() и hashCode().
Составные элементы могут содержать компоненты, но не коллекции. Если ваш составной компонент сам содержит компоненты, используйте тэг <nested-composite-element>. Это достаточно редкий случай - коллекция компонентов, каждый из которых содержит компоненты. В таком случае вам следует спросить себя, может ассоциация один ко многим (one-to-many) будет более подходящей. Попробуйте смоделировать составной элемент как сущность, но учтите, что, несмотря на то, что Java модель та же самая, реляционная модель и персистентная семантика по-прежнему немного различны.
Учтите, что отображение композитных элементов не поддерживает необязательные (null-able) свойства, когда используется <set>. При удалении Hibernate использует значения каждого столбца для идентификации удаляемых объектов (это связано с тем, что в таблицах с составными элементами не существует выделенного первичного ключа), что невозможно для null значений. Вы должны использовать только обязательные (not-null) свойства в составных элементах или использовать <list>, <map>, <bag> или <idbag>.
Особый случай составного элемента, это составной элемент с вложенным <many-to-one> элементом. Подобный маппинг, позволяет отображать дополнительные колонки ссылочной (many-to-many) таблицы на элементы составного класса. Следующий пример ассоциации многие ко многим (many-to-many) Order с Item, где purchaseDate, price и quantity свойства ассоциации:
<class name="eg.Order" .... > .... <set name="purchasedItems" table="purchase_items" lazy="true"> <key column="order_id"> <composite-element class="eg.Purchase"> <property name="purchaseDate"/> <property name="price"/> <property name="quantity"/> <many-to-one name="item" class="eg.Item"/> <!-- атрибут "class" необязателен --> </composite-element> </set> </class>
Для тернарных (или кватернарных, и т.д.) ассоциаций:
<class name="eg.Order" .... > .... <set name="purchasedItems" table="purchase_items" lazy="true"> <key column="order_id"> <composite-element class="eg.OrderLine"> <many-to-one name="purchaseDetails class="eg.Purchase"/> <many-to-one name="item" class="eg.Item"/> </composite-element> </set> </class>
Составные элементы могут применяться в запросах, используя обычный синтаксис ассоциаций с другими сущностями.
Элемент <composite-index> позволяет использовать класс компонента, как ключ Map. Убедитесь, что вы верно переопределили методы hashCode() и equals() в классе компонента.
Вы можете использовать компонент как идентификатор класса сущности. Ваш класс компонента должен удовлетворять следующим требованиям:
Он должен реализовать java.io.Serializable.
Он должен переопределить методы equals() и hashCode(), в соответствии с идентичностью составных ключей реляционной модели.
Вы не можете использовать IdentifierGenerator для генерации составных ключей. Вместо этого приложение должно устанавливать идентификаторы самостоятельно.
Т.к. составной идентификатор должен быть присвоен объекту до его сохранения, мы не можем использовать unsaved-value идентификатора, для различия созданного экземпляра и сохранённого в предыдущей сессии.
Вместо этого вы можете реализовать Interceptor.isUnsaved(), если вы хотите использовать saveOrUpdate() или каскадное сохранения / удаление (cascade save / delete). Как альтернатива, вы можете определить значение атрибута unsaved-value элемента <version> (или <timestamp>), для указания признака, не сохранённого (transient) экземпляра. В этом случае, используется версия сущности вместо (назначенного) идентификатора и вам не придётся реализовывать Interceptor.isUnsaved() самостоятельно.
Для объявления класса составного идентификатора, вместо <id> используйте тэг <composite-id> (атрибуты и элементы такие же, как и у <component>):
<class name="eg.Foo" table"FOOS"> <composite-id name="compId" class="eg.FooCompositeID"> <key-property name="string"/> <key-property name="short"/> <key-property name="date" column="date_" type="date"/> </composite-id> <property name="name"/> .... </class>
Теперь, все внешние ключи, указывающие на таблицу FOOS, также составные. Вы должны указать это в маппинге, других классов. Ассоциации на Foo должны быть объявлены так:
<many-to-one name="foo" class="eg.Foo"> <!-- атрибут "class" необязателен --> <column name="foo_string"/> <column name="foo_short"/> <column name="foo_date"/> </many-to-one>
Этот новый тег <column> также используется для определения много-стобцовых (multi-column) пользовательских типов (custom types). Его можно использовать как альтернативу элементу column. Коллекция с элементами типа Foo определяется так:
<set name="foos"> <key column="owner_id"/> <many-to-many class="eg.Foo"> <column name="foo_string"/> <column name="foo_short"/> <column name="foo_date"/> </many-to-many> </set>
С другой стороны, <one-to-many>, обычно, не объявляет столбцов.
Если Foo сам содержит коллекции, они также используют составной внешний ключ.
<class name="eg.Foo"> .... .... <set name="dates" lazy="true"> <key> <!-- коллекция наследует составной тип ключа --> <column name="foo_string"/> <column name="foo_short"/> <column name="foo_date"/> </key> <element column="foo_date" type="date"/> </set> </class>
Вы можете отобразить свойство типа Map:
<dynamic-component name="userAttributes"> <property name="foo" column="FOO"/> <property name="bar" column="BAR"/> <many-to-one name="baz" class="eg.Baz" column="BAZ"/> </dynamic-component>
Семантика отображения <dynamic-component> идентична <component>. Преимущество такого способа отображения, в возможности определять истинное свойство бина в момент развёртывания, редактируя документ маппинга. (Изменение документа маппинга во время выполнения также возможно, используя DOM парсер.)
Hibernate поддерживает три базовые стратегии маппинга наследников.
table per class hierarchy
table per subclass
table per concrete class (с некоторыми ограничениями)
Возмножно использование разных стратегий маппинга для различных веток одной и той же иерархии наследников, но есть некоторые ограничения для стратегии маппинга table-per-concrete class. Hibernate не поддерживает одновременного использования <subclass> маппинга и <joined-subclass> маппинга в одном элементе <class>
Допустим у нас есть интерфейс Payment и классы CreditCardPayment, CashPayment, ChequePayment, которые его реализуют. Маппинг table-per-hierarchy может выглядеть так:
<class name="Payment" table="PAYMENT"> <id name="id" type="long" column="PAYMENT_ID"> <generator class="native"/> </id> <discriminator column="PAYMENT_TYPE" type="string"/> <property name="amount" column="AMOUNT"/> ... <subclass name="CreditCardPayment" discriminator-value="CREDIT"> ... </subclass> <subclass name="CashPayment" discriminator-value="CASH"> ... </subclass> <subclass name="ChequePayment" discriminator-value="CHEQUE"> ... </subclass> </class>
Используется только одна таблица для всех классов. В этой стратегии маппинга есть одно сильное ограничение: столбцы которые определены в подкассах не могут быть NOT NULL.
Маппинг table-per-subclass может выглядеть примерно так:
<class name="Payment" table="PAYMENT"> <id name="id" type="long" column="PAYMENT_ID"> <generator class="native"/> </id> <property name="amount" column="AMOUNT"/> ... <joined-subclass name="CreditCardPayment" table="CREDIT_PAYMENT"> <key column="PAYMENT_ID"/> ... </joined-subclass> <joined-subclass name="CashPayment" table="CASH_PAYMENT"> <key column="PAYMENT_ID"/> ... </joined-subclass> <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT"> <key column="PAYMENT_ID"/> ... </joined-subclass> </class>
В данном случае требуются четыре таблицы. Три таблицы подклассов ассоциируются с таблицей суперкласса по первичному ключу (в реляционной модели это в действительности отношение один к одному).
Заметьте, что реализация table-per-subclass в Hibernate не требует столбцов-дискриминаторов. Другие продукты для объекто-реляционного отображения используют модель реализации стратегии table-per-subclass, требующую определения столбца-дискриминатора в таблице суперкласса. Подход используемый в Hibernate намного более труден в реализации, но, вероятно, более корректен с точки зрения проектирования реляционной модели.
Для любой из этих двух стратегий маппинга, полиморфические ассоциации к Payment маппятся используя <many-to-one>.
<many-to-one name="payment" column="PAYMENT" class="Payment"/>
Стратегия маппинга table-per-concrete-class очень сильно отличается от остальных.
<class name="CreditCardPayment" table="CREDIT_PAYMENT"> <id name="id" type="long" column="CREDIT_PAYMENT_ID"> <generator class="native"/> </id> <property name="amount" column="CREDIT_AMOUNT"/> ... </class> <class name="CashPayment" table="CASH_PAYMENT"> <id name="id" type="long" column="CASH_PAYMENT_ID"> <generator class="native"/> </id> <property name="amount" column="CASH_AMOUNT"/> ... </class> <class name="ChequePayment" table="CHEQUE_PAYMENT"> <id name="id" type="long" column="CHEQUE_PAYMENT_ID"> <generator class="native"/> </id> <property name="amount" column="CHEQUE_AMOUNT"/> ... </class>
Требуются три таблицы. Заметьте, что нигде явно не упоминается связь с интерфейсом Payment. Вместо этого используется Hibernate'овский неявный полиморфизм (implicit polymorphism). Так же заметьте, что свойства интерфейса Payment определяются для каждого из подклассов.
В данном случае случае полиморфическая ассоциация к Payment маппится с использованием <any>.
<any name="payment" meta-type="class" id-type="long"> <column name="PAYMENT_CLASS"/> <column name="PAYMENT_ID"/> </any>
Будет лучше, если в качестве meta-type мы укажем пользовательский тип, для определения маппинга подклассов Payment.
<any name="payment" meta-type="PaymentMetaType" id-type="long"> <column name="PAYMENT_TYPE"/> <!-- CREDIT, CASH или CHEQUE --> <column name="PAYMENT_ID"/> </any>
Есть еще одна дополтинельная вещь, которую нужно учитывать при данном маппинге. Так как подклассы определены в элементах <class> (и Payment интерфейс к ним), каждый из подклассов может в свою очередь использовать стратегии маппинга table-per-class или table-per-subclass! (При этом остается возможность использования полиморфических запросов к интерфейсу Payment.)
<class name="CreditCardPayment" table="CREDIT_PAYMENT"> <id name="id" type="long" column="CREDIT_PAYMENT_ID"> <generator class="native"/> </id> <discriminator column="CREDIT_CARD" type="string"/> <property name="amount" column="CREDIT_AMOUNT"/> ... <subclass name="MasterCardPayment" discriminator-value="MDC"/> <subclass name="VisaPayment" discriminator-value="VISA"/> </class> <class name="NonelectronicTransaction" table="NONELECTRONIC_TXN"> <id name="id" type="long" column="TXN_ID"> <generator class="native"/> </id> ... <joined-subclass name="CashPayment" table="CASH_PAYMENT"> <key column="PAYMENT_ID"/> <property name="amount" column="CASH_AMOUNT"/> ... </joined-subclass> <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT"> <key column="PAYMENT_ID"/> <property name="amount" column="CHEQUE_AMOUNT"/> ... </joined-subclass> </class>
Повторим, что мы не ссылается на Payment явно. При исполнении запроса по интерфейсу Payment, например from Payment, Hibernate автоматически возвращает экземпляры CreditCardPayment (и его подклассы, они так же реализуют интерфейс Payment), CashPayment и ChequePayment но не NonelectronicTransaction. Once again, we don't mention Payment explicitly. If we execute a query against the Payment interface - for example, from Payment - Hibernate automatically returns instances of CreditCardPayment (and its subclasses, since they also implement Payment), CashPayment and ChequePayment but not instances of NonelectronicTransaction.
Hiberante предполагает, что ассоциация отображается на единственный столбец foreign key. Множественные ассоциации для по одному и тому же foreign key допускаются (возможно потребуется указать inverse="true" или insert="false" update="false"), но не существует возможности отображения одной ассоциации на множество foreign keys. Это означает вот что:
когда ассоциация модифицируется, всегда обновляется один и тот же foreign key.
когда происходит ленивая выборка по ассоциациям используется один и тот же запрос.
когда происходит "стремительная" (eagerly) выборка по ассоциации, используется один и тот же outer join.
Полиморфическая ассоциация один ко многим замапленная с использованием стратегии table-per-concrete-class не поддерживается. (Выборка по таким ассоциациям обычно требует нескольких запросов или множественных join'ов.)
А нижеследующей таблице перечисленны ограничения маппинга table-per-concrete-class и неявного полиморфизма в Hibernate.
Таблица 8.1. Возможности маппинга наследников
Стратегия наследования | Polymorphic many-to-one | Polymorphic one-to-one | Polymorphic one-to-many | Polymorphic many-to-many | Polymorphic load()/get() | Polymorphic queries | Polymorphic joins | Outer join fetching |
---|---|---|---|---|---|---|---|---|
table-per-class-hierarchy | <many-to-one> | <one-to-one> | <one-to-many> | <many-to-many> | s.get(Payment.class, id) | from Payment p | from Order o join o.payment p | поддерживается |
table-per-subclass | <many-to-one> | <one-to-one> | <one-to-many> | <many-to-many> | s.get(Payment.class, id) | from Payment p | from Order o join o.payment p | поддерживается |
table-per-concrete-class (неявный полиморфизм) | <any> | не поддерживается | не поддерживается | <many-to-any> | use a query | from Payment p | не поддерживается | не поддерживается |
An object (entity instance) is either transient or persistent with respect to a particular Session. Newly instantiated objects are, of course, transient. The session offers services for saving (ie. persisting) transient instances:
DomesticCat fritz = new DomesticCat(); fritz.setColor(Color.GINGER); fritz.setSex('M'); fritz.setName("Fritz"); Long generatedId = (Long) sess.save(fritz);
DomesticCat pk = new DomesticCat(); pk.setColor(Color.TABBY); pk.setSex('F'); pk.setName("PK"); pk.setKittens( new HashSet() ); pk.addKitten(fritz); sess.save( pk, new Long(1234) );
The single-argument save() generates and assigns a unique identifier to fritz. The two-argument form attempts to persist pk using the given identifier. We generally discourage the use of the two-argument form since it may be used to create primary keys with business meaning. It is most useful in certain special situations like using Hibernate to persist a BMP entity bean.
Associated objects may be made persistent in any order you like unless you have a NOT NULL constraint upon a foreign key column. There is never a risk of violating foreign key constraints. However, you might violate a NOT NULL constraint if you save() the objects in the wrong order.
The load() methods of Session give you a way to retrieve a persistent instance if you already know its identifier. One version takes a class object and will load the state into a newly instantiated object. The second version allows you to supply an instance into which the state will be loaded. The form which takes an instance is particularly useful if you plan to use Hibernate with BMP entity beans and is provided for exactly that purpose. You may discover other uses. (DIY instance pooling etc.)
Cat fritz = (Cat) sess.load(Cat.class, generatedId);
// you need to wrap primitive identifiers long pkId = 1234; DomesticCat pk = (DomesticCat) sess.load( Cat.class, new Long(pkId) );
Cat cat = new DomesticCat(); // load pk's state into cat sess.load( cat, new Long(pkId) ); Set kittens = cat.getKittens();
Note that load() will throw an unrecoverable exception if there is no matching database row. If the class is mapped with a proxy, load() returns an object that is an uninitialized proxy and does not actually hit the database until you invoke a method of the object. This behaviour is very useful if you wish to create an association to an object without actually loading it from the database.
If you are not certain that a matching row exists, you should use the get() method, which hits the database immediately and returns null if there is no matching row.
Cat cat = (Cat) sess.get(Cat.class, id); if (cat==null) { cat = new Cat(); sess.save(cat, id); } return cat;
You may also load an objects using an SQL SELECT ... FOR UPDATE. See the next section for a discussion of Hibernate LockModes.
Cat cat = (Cat) sess.get(Cat.class, id, LockMode.UPGRADE);
Note that any associated instances or contained collections are not selected FOR UPDATE.
It is possible to re-load an object and all its collections at any time, using the refresh() method. This is useful when database triggers are used to initialize some of the properties of the object.
sess.save(cat); sess.flush(); //force the SQL INSERT sess.refresh(cat); //re-read the state (after the trigger executes)
If you don't know the identifier(s) of the object(s) you are looking for, use the find() methods of Session. Hibernate supports a simple but powerful object oriented query language.
List cats = sess.find( "from Cat as cat where cat.birthdate = ?", date, Hibernate.DATE ); List mates = sess.find( "select mate from Cat as cat join cat.mate as mate " + "where cat.name = ?", name, Hibernate.STRING ); List cats = sess.find( "from Cat as cat where cat.mate.bithdate is null" ); List moreCats = sess.find( "from Cat as cat where " + "cat.name = 'Fritz' or cat.id = ? or cat.id = ?", new Object[] { id1, id2 }, new Type[] { Hibernate.LONG, Hibernate.LONG } ); List mates = sess.find( "from Cat as cat where cat.mate = ?", izi, Hibernate.entity(Cat.class) ); List problems = sess.find( "from GoldFish as fish " + "where fish.birthday > fish.deceased or fish.birthday is null" );
The second argument to find() accepts an object or array of objects. The third argument accepts a Hibernate type or array of Hibernate types. These given types are used to bind the given objects to the ? query placeholders (which map to IN parameters of a JDBC PreparedStatement). Just as in JDBC, you should use this binding mechanism in preference to string manipulation.
The Hibernate class defines a number of static methods and constants, providing access to most of the built-in types, as instances of net.sf.hibernate.type.Type.
If you expect your query to return a very large number of objects, but you don't expect to use them all, you might get better performance from the iterate() methods, which return a java.util.Iterator. The iterator will load objects on demand, using the identifiers returned by an initial SQL query (n+1 selects total).
// fetch ids Iterator iter = sess.iterate("from eg.Qux q order by q.likeliness"); while ( iter.hasNext() ) { Qux qux = (Qux) iter.next(); // fetch the object // something we couldnt express in the query if ( qux.calculateComplicatedAlgorithm() ) { // delete the current instance iter.remove(); // dont need to process the rest break; } }
Unfortunately java.util.Iterator does not declare any exceptions, so any SQL or Hibernate exceptions that occur are wrapped in a LazyInitializationException (a subclass of RuntimeException).
The iterate() method also performs better if you expect that many of the objects are already loaded and cached by the session, or if the query results contain the same objects many times. (When no data is cached or repeated, find() is almost always faster.) Heres an example of a query that should be called using iterate():
Iterator iter = sess.iterate( "select customer, product " + "from Customer customer, " + "Product product " + "join customer.purchases purchase " + "where product = purchase.product" );
Calling the previous query using find() would return a very large JDBC ResultSet containing the same data many times.
Hibernate queries sometimes return tuples of objects, in which case each tuple is returned as an array:
Iterator foosAndBars = sess.iterate( "select foo, bar from Foo foo, Bar bar " + "where bar.date = foo.date" ); while ( foosAndBars.hasNext() ) { Object[] tuple = (Object[]) foosAndBars.next(); Foo foo = tuple[0]; Bar bar = tuple[1]; .... }
Queries may specify a property of a class in the select clause. They may even call SQL aggregate functions. Properties or aggregates are considered "scalar" results.
Iterator results = sess.iterate( "select cat.color, min(cat.birthdate), count(cat) from Cat cat " + "group by cat.color" ); while ( results.hasNext() ) { Object[] row = results.next(); Color type = (Color) row[0]; Date oldest = (Date) row[1]; Integer count = (Integer) row[2]; ..... }
Iterator iter = sess.iterate( "select cat.type, cat.birthdate, cat.name from DomesticCat cat" );
List list = sess.find( "select cat, cat.mate.name from DomesticCat cat" );
If you need to specify bounds upon your result set (the maximum number of rows you want to retrieve and / or the first row you want to retrieve) you should obtain an instance of net.sf.hibernate.Query:
Query q = sess.createQuery("from DomesticCat cat"); q.setFirstResult(20); q.setMaxResults(10); List cats = q.list();
You may even define a named query in the mapping document. (Remember to use a CDATA section if your query contains characters that could be interpreted as markup.)
<query name="eg.DomesticCat.by.name.and.minimum.weight"><![CDATA[ from eg.DomesticCat as cat where cat.name = ? and cat.weight > ? ] ]></query>
Query q = sess.getNamedQuery("eg.DomesticCat.by.name.and.minimum.weight"); q.setString(0, name); q.setInt(1, minWeight); List cats = q.list();
The query interface supports the use of named parameters. Named parameters are identifiers of the form :name in the query string. There are methods on Query for binding values to named parameters or JDBC-style ? parameters. Contrary to JDBC, Hibernate numbers parameters from zero. The advantages of named parameters are:
named parameters are insensitive to the order they occur in the query string
they may occur multiple times in the same query
they are self-documenting
//named parameter (preferred) Query q = sess.createQuery("from DomesticCat cat where cat.name = :name"); q.setString("name", "Fritz"); Iterator cats = q.iterate();
//positional parameter Query q = sess.createQuery("from DomesticCat cat where cat.name = ?"); q.setString(0, "Izi"); Iterator cats = q.iterate();
//named parameter list List names = new ArrayList(); names.add("Izi"); names.add("Fritz"); Query q = sess.createQuery("from DomesticCat cat where cat.name in (:namesList)"); q.setParameterList("namesList", names); List cats = q.list();
If your JDBC driver supports scrollable ResultSets, the Query interface may be used to obtain a ScrollableResults which allows more flexible navigation of the query results.
Query q = sess.createQuery("select cat.name, cat from DomesticCat cat " + "order by cat.name"); ScrollableResults cats = q.scroll(); if ( cats.first() ) { // find the first name on each page of an alphabetical list of cats by name firstNamesOfPages = new ArrayList(); do { String name = cats.getString(0); firstNamesOfPages.add(name); } while ( cats.scroll(PAGE_SIZE) ); // Now get the first page of cats pageOfCats = new ArrayList(); cats.beforeFirst(); int i=0; while( ( PAGE_SIZE > i++ ) && cats.next() ) pageOfCats.add( cats.get(1) ); }
The behaviour of scroll() is similar to iterate(), except that objects may be initialized selectively by get(int), instead of an entire row being initialized at once.
A collection filter is a special type of query that may be applied to a persistent collection or array. The query string may refer to this, meaning the current collection element.
Collection blackKittens = session.filter( pk.getKittens(), "where this.color = ?", Color.BLACK, Hibernate.enum(Color.class) );
The returned collection is considered a bag.
Observe that filters do not require a from clause (though they may have one if required). Filters are not limited to returning the collection elements themselves.
Collection blackKittenMates = session.filter( pk.getKittens(), "select this.mate where this.color = eg.Color.BLACK" );
HQL is extremely powerful but some people prefer to build queries dynamically, using an object oriented API, rather than embedding strings in their Java code. For these people, Hibernate provides an intuitive Criteria query API.
Criteria crit = session.createCriteria(Cat.class); crit.add( Expression.eq("color", eg.Color.BLACK) ); crit.setMaxResults(10); List cats = crit.list();
If you are uncomfortable with SQL-like syntax, this is perhaps the easiest way to get started with Hibernate. This API is also more extensible than HQL. Applications might provide their own implementations of the Criterion interface.
You may express a query in SQL, using createSQLQuery(). You must enclose SQL aliases in braces.
List cats = session.createSQLQuery( "SELECT {cat.*} FROM CAT {cat} WHERE ROWNUM<10", "cat", Cat.class ).list();
List cats = session.createSQLQuery( "SELECT {cat}.ID AS {cat.id}, {cat}.SEX AS {cat.sex}, " + "{cat}.MATE AS {cat.mate}, {cat}.SUBCLASS AS {cat.class}, ... " + "FROM CAT {cat} WHERE ROWNUM<10", "cat", Cat.class ).list()
SQL queries may contain named and positional parameters, just like Hibernate queries.
Transactional persistent instances (ie. objects loaded, saved, created or queried by the Session) may be manipulated by the application and any changes to persistent state will be persisted when the Session is flushed (discussed later in this chapter). So the most straightforward way to update the state of an object is to load() it, and then manipulate it directly, while the Session is open:
DomesticCat cat = (DomesticCat) sess.load( Cat.class, new Long(69) ); cat.setName("PK"); sess.flush(); // changes to cat are automatically detected and persisted
Sometimes this programming model is inefficient since it would require both an SQL SELECT (to load an object) and an SQL UPDATE (to persist its updated state) in the same session. Therefore Hibernate offers an alternate approach.
Many applications need to retrieve an object in one transaction, send it to the UI layer for manipulation, then save the changes in a new transaction. (Applications that use this kind of approach in a high-concurrency environment usually use versioned data to ensure transaction isolation.) This approach requires a slightly different programming model to the one described in the last section. Hibernate supports this model by providing the method Session.update().
// in the first session Cat cat = (Cat) firstSession.load(Cat.class, catId); Cat potentialMate = new Cat(); firstSession.save(potentialMate); // in a higher tier of the application cat.setMate(potentialMate); // later, in a new session secondSession.update(cat); // update cat secondSession.update(mate); // update mate
If the Cat with identifier catId had already been loaded by secondSession when the application tried to update it, an exception would have been thrown.
The application should individually update() transient instances reachable from the given transient instance if and only if it wants their state also updated. (Except for lifecycle objects, discussed later.)
Hibernate users have requested a general purpose method that either saves a transient instance by generating a new identifier or update the persistent state associated with its current identifier. The saveOrUpdate() method now implements this functionality.
Hibernate distinguishes "new" (unsaved) instances from "existing" (saved or loaded in a previous session) instances by the value of their identifier (or version, or timestamp) property. The unsaved-value attribute of the <id> (or <version>, or <timestamp>) mapping specifies which values should be interpreted as representing a "new" instance.
<id name="id" type="long" column="uid" unsaved-value="null"> <generator class="hilo"/> </id>
The allowed values of unsaved-value are:
any - always save
none - always update
null - save when identifier is null (this is the default)
valid identifier value - save when identifier is null or the given value
undefined - the default for version or timestamp, then identifier check is used
// in the first session Cat cat = (Cat) firstSession.load(Cat.class, catID); // in a higher tier of the application Cat mate = new Cat(); cat.setMate(mate); // later, in a new session secondSession.saveOrUpdate(cat); // update existing state (cat has a non-null id) secondSession.saveOrUpdate(mate); // save the new instance (mate has a null id)
The usage and semantics of saveOrUpdate() seems to be confusing for new users. Firstly, so long as you are not trying to use instances from one session in another new session, you should not need to use update() or saveOrUpdate(). Some whole applications will never use either of these methods.
Usually update() or saveOrUpdate() are used in the following scenario:
the application loads an object in the first session
the object is passed up to the UI tier
some modifications are made to the object
the object is passed back down to the business logic tier
the application persists these modifications by calling update() in a second session
saveOrUpdate() does the following:
if the object is already persistent in this session, do nothing
if the object has no identifier property, save() it
if the object's identifier matches the criteria specified by unsaved-value, save() it
if the object is versioned (version or timestamp), then the version will take precedence to identifier check, unless the versions unsaved-value="undefined" (default value)
if another object associated with the session has the same identifier, throw an exception
The lock() method allows the application to reassociate an unmodified object with a new session.
//just reassociate: sess.lock(fritz, LockMode.NONE); //do a version check, then reassociate: sess.lock(izi, LockMode.READ); //do a version check, using SELECT ... FOR UPDATE, then reassociate: sess.lock(pk, LockMode.UPGRADE);
Session.delete() will remove an object's state from the database. Of course, your application might still hold a reference to it. So it's best to think of delete() as making a persistent instance transient.
sess.delete(cat);
You may also delete many objects at once by passing a Hibernate query string to delete().
You may now delete objects in any order you like, without risk of foreign key constraint violations. Of course, it is still possible to violate a NOT NULL constraint on a foreign key column by deleting objects in the wrong order.
From time to time the Session will execute the SQL statements needed to synchronize the JDBC connection's state with the state of objects held in memory. This process, flush, occurs by default at the following points
from some invocations of find() or iterate()
from net.sf.hibernate.Transaction.commit()
from Session.flush()
The SQL statements are issued in the following order
all entity insertions, in the same order the corresponding objects were saved using Session.save()
all entity updates
all collection deletions
all collection element deletions, updates and insertions
all collection insertions
all entity deletions, in the same order the corresponding objects were deleted using Session.delete()
(An exception is that objects using native ID generation are inserted when they are saved.)
Except when you explicity flush(), there are absolutely no guarantees about when the Session executes the JDBC calls, only the order in which they are executed. However, Hibernate does guarantee that the Session.find(..) methods will never return stale data; nor will they return the wrong data.
It is possible to change the default behavior so that flush occurs less frequently. The FlushMode class defines three different modes. This is most useful in the case of "readonly" transactions, where it might be used to achieve a (very) slight performance increase.
sess = sf.openSession(); Transaction tx = sess.beginTransaction(); sess.setFlushMode(FlushMode.COMMIT); //allow queries to return stale state Cat izi = (Cat) sess.load(Cat.class, id); izi.setName(iznizi); // execute some queries.... sess.find("from Cat as cat left outer join cat.kittens kitten"); //change to izi is not flushed! ... tx.commit(); //flush occurs
Ending a session involves four distinct phases:
flush the session
commit the transaction
close the session
handle exceptions
If you happen to be using the Transaction API, you don't need to worry about this step. It will be performed implicitly when the transaction is committed. Otherwise you should call Session.flush() to ensure that all changes are synchronized with the database.
If you are using the Hibernate Transaction API, this looks like:
tx.commit(); // flush the Session and commit the transaction
If you are managing JDBC transactions yourself you should manually commit() the JDBC connection.
sess.flush(); sess.connection().commit(); // not necessary for JTA datasource
If you decide not to commit your changes:
tx.rollback(); // rollback the transaction
or:
// not necessary for JTA datasource, important otherwise sess.connection().rollback();
If you rollback the transaction you should immediately close and discard the current session to ensure that Hibernate's internal state is consistent.
A call to Session.close() marks the end of a session. The main implication of close() is that the JDBC connection will be relinquished by the session.
tx.commit(); sess.close();
sess.flush(); sess.connection().commit(); // not necessary for JTA datasource sess.close();
If you provided your own connection, close() returns a reference to it, so you can manually close it or return it to the pool. Otherwise close() returns it to the pool.
If the Session throws an exception (including any SQLException), you should immediately rollback the transaction, call Session.close() and discard the Session instance. Certain methods of Session will not leave the session in a consistent state.
The following exception handling idiom is recommended:
Session sess = factory.openSession(); Transaction tx = null; try { tx = sess.beginTransaction(); // do some work ... tx.commit(); } catch (Exception e) { if (tx!=null) tx.rollback(); throw e; } finally { sess.close(); }
Or, when manually managing JDBC transactions:
Session sess = factory.openSession(); try { // do some work ... sess.flush(); sess.connection().commit(); } catch (Exception e) { sess.connection().rollback(); throw e; } finally { sess.close(); }
Or, when using a datasource enlisted with JTA:
UserTransaction ut = .... ; Session sess = factory.openSession(); try { // do some work ... sess.flush(); } catch (Exception e) { ut.setRollbackOnly(); throw e; } finally { sess.close(); }
To save or update all objects in a graph of associated objects, you must either
save(), saveOrUpdate() or update() each individual object OR
map associated objects using cascade="all" or cascade="save-update".
Likewise, to delete all objects in a graph, either
delete() each individual object OR
map associated objects using cascade="all", cascade="all-delete-orphan" or cascade="delete".
Recommendation:
If the child object's lifespan is bounded by the lifespan of the of the parent object make it a lifecycle object by specifying cascade="all".
Otherwise, save() and delete() it explicitly from application code. If you really want to save yourself some extra typing, use cascade="save-update" and explicit delete().
Mapping an association (many-to-one, or collection) with cascade="all" marks the association as a parent/child style relationship where save/update/deletion of the parent results in save/update/deletion of the child(ren). Futhermore, a mere reference to a child from a persistent parent will result in save / update of the child. The metaphor is incomplete, however. A child which becomes unreferenced by its parent is not automatically deleted, except in the case of a <one-to-many> association mapped with cascade="all-delete-orphan". The precise semantics of cascading operations are as follows:
If a parent is saved, all children are passed to saveOrUpdate()
If a parent is passed to update() or saveOrUpdate(), all children are passed to saveOrUpdate()
If a transient child becomes referenced by a persistent parent, it is passed to saveOrUpdate()
If a parent is deleted, all children are passed to delete()
If a transient child is dereferenced by a persistent parent, nothing special happens (the application should explicitly delete the child if necessary) unless cascade="all-delete-orphan", in which case the "orphaned" child is deleted.
Hibernate does not fully implement "persistence by reachability", which would imply (inefficient) persistent garbage collection. However, due to popular demand, Hibernate does support the notion of entities becoming persistent when referenced by another persistent object. Associations marked cascade="save-update" behave in this way. If you wish to use this approach throughout your application, its easier to specify the default-cascade attribute of the <hibernate-mapping> element.
The Interceptor interface provides callbacks from the session to the application allowing the application to inspect and / or manipulate properties of a persistent object before it is saved, updated, deleted or loaded. One possible use for this is to track auditing information. For example, the following Interceptor automatically sets the createTimestamp when an Auditable is created and updates the lastUpdateTimestamp property when an Auditable is updated.
package net.sf.hibernate.test; import java.io.Serializable; import java.util.Date; import java.util.Iterator; import net.sf.hibernate.Interceptor; import net.sf.hibernate.type.Type; public class AuditInterceptor implements Interceptor, Serializable { private int updates; private int creates; public void onDelete(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) { // do nothing } public boolean onFlushDirty(Object entity, Serializable id, Object[] currentState, Object[] previousState, String[] propertyNames, Type[] types) { if ( entity instanceof Auditable ) { updates++; for ( int i=0; i < propertyNames.length; i++ ) { if ( "lastUpdateTimestamp".equals( propertyNames[i] ) ) { currentState[i] = new Date(); return true; } } } return false; } public boolean onLoad(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) { return false; } public boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) { if ( entity instanceof Auditable ) { creates++; for ( int i=0; i<propertyNames.length; i++ ) { if ( "createTimestamp".equals( propertyNames[i] ) ) { state[i] = new Date(); return true; } } } return false; } public void postFlush(Iterator entities) { System.out.println("Creations: " + creates + ", Updates: " + updates); } public void preFlush(Iterator entities) { updates=0; creates=0; } ...... ...... }
The interceptor would be specified when a session is created.
Session session = sf.openSession( new AuditInterceptor() );
Hibernate requires a very rich meta-level model of all entity and value types. From time to time, this model is very useful to the application itself. For example, the application might use Hibernate's metadata to implement a "smart" deep-copy algorithm that understands which objects should be copied (eg. mutable value types) and which should not (eg. immutable value types and, possibly, associated entities).
Hibernate exposes metadata via the ClassMetadata and CollectionMetadata interfaces and the Type hierarchy. Instances of the metadata interfaces may be obtained from the SessionFactory.
Cat fritz = ......; Long id = (Long) catMeta.getIdentifier(fritz); ClassMetadata catMeta = sessionfactory.getClassMetadata(Cat.class); Object[] propertyValues = catMeta.getPropertyValues(fritz); String[] propertyNames = catMeta.getPropertyNames(); Type[] propertyTypes = catMeta.getPropertyTypes(); // get a Map of all properties which are not collections or associations // TODO: what about components? Map namedValues = new HashMap(); for ( int i=0; i<propertyNames.length; i++ ) { if ( !propertyTypes[i].isEntityType() && !propertyTypes[i].isCollectionType() ) { namedValues.put( propertyNames[i], propertyValues[i] ); } }
Hibernate не является базой данных. Это легковесный иструмент объектно-реляционного отображения (маппинга). Управление транзакциями делегируется на уровень базы данных. Если соединение с базой данных вовлечена с JTA, операции выполняемые Session автоматически становятся частью JTA транзакции. В этом смысле Hibernate можно рассматривать как тонкий адаптер к JDBC, добавляющий объектно ориентированные семантики.
SessionFactory это дорогой в создании, объект предусматривающий паралельные вызовы (threadsafe). Он предназначен для работы в режиме одновременного доступа из любого потока приложения. Session в свою очередь объект дешевый и не не расчитанный на работу в многопоточном режиме (non-threadsafe). Он используется один раз для выполения единичной бизнес-операции и затем отбрасывается. Например, при использовании Hibernate в основанном на сервлетах приложении, сервлет может получить SessionFactory используя следующий вызов:
SessionFactory sf = (SessionFactory)getServletContext().getAttribute("my.session.factory");
Каждый вызов метода service может создать новый экземпляр сессии Session, сбросить его (вызовом метода flush()), зафиксировать тразнакцию (вызовом метода commit()), закрыть сессию (метод close()) и в завершении отбросить его. (SessionFactory в сво. очередь может хранится в JNDI или в статической переменной какого-нибудь Singleton'а.)
Для stateless session bean может использоваться похожий же подход. SessionFactory можно получать в методе setSessionContext(). Каждый бизнес-метод может создавать Session, сбрасывать ее (flush()) и закрывать (close()). (Оставляя транзакции на совести JTA, которая управляет ими автоматически в модели container-managed transactions.)
Мы используем транзакции (Hibernate Transaction) как это описано выше, единственный метод commit() Hibernate Transaction сбрасывает состояние и фиксирует транзакцию базы данных (со специальной обработкой в случае использования JTA транзакций).
Убедитесь в том, что вы поняли семантику метода flush(). Сбрасывание синхронизирует персистентное хранилище с изменениями которые произошли в памяти но не наобарот. Учтите что для всех Hibernate JDBC транзакций/соединений, транзакционный уровень изоляции применяется для всех операций исполняемых Hibernate!
В следующих разделах будут рассмотрены альтернативные подходы которые используют версионность для обеспечения атомарности тразакций. Это продуманные "передовые" подходы при приминении которых нужно проявлять внимательность и осторожность.
Вы должны обратить внимание на следующие практики создания сессий Hibernate:
Никогда не создавайте в одном потоке более чем один экземпляр Session или Transaction для каждого соединения с базой данных в одном потоке.
Будьте предельно внимательны при создании более чем одной Session для каждой базы данных каждой транзакции. Сама по себе сессия Session содержит информацию об изменениях осуществленных для загруженных объектов, таким образом другая сессия Session может содержать устаревшие данные.
Объект Session не предназначен к одновременному использованию из нескольких потоков (not threadsafe)! Никогда не разделяйте доступ к одному и тому же экземпляру сессии Session между разными потоками. Сессию обычно используют в контексте одной единицы работы (unit-of-work)!
Приложение может получить одновременный доступ из разных единиц работы к одному и тому же состоянию персистентности. Однако один и тот же экземпляр персистентного класса никогда не разделяется между между двумя сессиями (экземплярами Session). Поэтому существует два различных преставления идентичности:
foo.getId().equals( bar.getId() )
foo==bar
Для объектов одной сессии (Session) эти два представления эквивалентны. Однако, при одновременном доступе из разных потоков к одному и тому же бизнес объекту в контексте двух различных сессий, они различаются с точки зрения идентичности JVM.
Такой подход предоставляет Hibernae и базе данных беспокоится по поводу одновременного доступа. Приложению нет нужды синхронизировать каждый бизнес-объект, так как сессия использует его в одном потоке. Приложение так же не беспокоится о идентичности и может использовать == для сравнения объектов.
Многие бизнес-процессы требуют чтобы вся последовательность взаимодействия с пользованелем перемежалось с досупом к базе данных. В веб- и промышленных (enterprise) приложениях неприемлемо совмещение транзакции базы данных с полным циклом взаимодейтсвия с пользователем.
Поддержка изоляции бизнес-процессов частично переходит в зону отвественности звена приложения, следовательно мы называем такой процесс долгоисполняющейся транзакцией приложения. Одна транзакция приложения обычно состоит из множества транзакций к базе данных. Она атомарна если только одна (последняя) из транзакций к базе данных сохраняет данные, а все остальные только считывают.
Только подход оптимистичного контроля конкурентности обеспечивает высокую производительность и расширяемость. Hibernate поддерживает три возможных пути для написания кода приложений с использованием стратегии оптимистической конкурентности.
Для всех транзакций приложения используется единственный экзепляр Session и ее персистентые объекты.
Сессия (Session) использует оптимистическое блокирование с версионностью для гарантии того, что множество транзакций базы данных являются одной транзакцией уровня приложения. Сессия (Session) отключается от JDBC коннекции когда приложение ожидает действия пользователя. Данный подход наиболее эффективен в терминах доступа к базе данных. Приложению не нужно осуществлять версионный контроль или переподключать отсоединенные (detached) экземпляры самостоятельно.
// Экземпляр foo был раньше загружен в сессию session.reconnect(); foo.setProperty("bar"); session.flush(); session.connection().commit(); session.disconnect();
Объект foo все еще опознаваем сессией в которая его загрузила. Пока в сессии Session есть JDBC содеинение, мы коммитим изменения в объект.
Такой прием проблематичен если наша сессия слишком велика для ее хранения в в период, когда пользователь думает (то есть между действиями пользователя), так как HttpSession должна быть настолько мала, насколько это возможно. Так как сессия (Session) так же (обязательно) является нешлм первого уровня и хранит все загруженные объекты, мы можем импользовать данную статегию отлько для ограниченого количества циклов запрос/ответ. Это действительно рекомендуется так как сессия так же со временем будет содержать устаревшие данные (объекты обновленные другими сессиями).
Каждое взаимодействие с персистентным хранилищем происходит в новой сессии. Несмотря на это, одни и те же персистентные экзепляры используются при каждом взаимодействии с базой данных. Приложение манипулирует отсоединенными (detached) экзеплярами которые были загружены другой сессией, затем повторно ассоциирует их вызывая Session.update() или Session.saveOrUpdate().
// foo- экзепляр, загруженный предыдущей сессией. foo.setProperty("bar"); session = factory.openSession(); session.saveOrUpdate(foo); session.flush(); session.connection().commit(); session.close();
Можно так же вызывать lock() вместо update() и использовать LockMode.READ (осуществяет проверку версии в обход всех кешей) если вы уверены в том, что объект не был модифицирован.
Каждое взаимодейcтсвие с базой данных происходит в новой сессии (Session), которая перезагружает все персистные экземпляры из базы данных перед тем как с ними работать. Этот подход вынуждает приложение самому заботиться о проверке версий для обеспечения изоляции тразакций (конечно-же, Hibernate все еще обновляет весии за вас). Данный подход наименее эффективен в терминах доступа к базе данных. Больше всего он похож на Entity EJB.
// foo - экземпляр загруженный в предыдущей сессии (Session) session = factory.openSession(); int oldVersion = foo.getVersion(); session.load( foo, foo.getKey() ); if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException(); foo.setProperty("bar"); session.flush(); session.connection().commit(); session.close();
Конечно, если вы оперируете в среде с низким уровнем конкурентного доступа к данным, и вам не требуется контроля версий, вы можете использовать данный подход и просто пропускать проверку версии.
Первый из подходов описанных выше заключается в хранении одной сессии для полного бизнес процесса, который так же включает в себя время размышления пользователя. (Для примера, сервлет может хранить такую сессиию (Session) в пользовательской HttpSession.) Для обеспечения должного уровня производительности вы должны
фиксировать (commit) транзакцию (Transaction) или JDBC соединение и затем
отсоединять сессию Session от JDBC.
перед тем как передавать управление пользователю. Метод Session.disconnect() отсоединяет сессию от JDBC соединения с базой данных и возвращает JDBC содединение в пул (unless you provided the connection).
Session.reconnect() получает новое соединение и перезапускает сессию. После восстановления соединения, для проведения проверки версии на данные, которые не обновлялись, вы можете вызвать Session.lock() для объектов которые могли быть обновлены в других транзакциях. При этом вам не нужно блокировать (lock) данные, которые вы обновляете.
Пример:
SessionFactory sessions; List fooList; Bar bar; .... Session s = sessions.openSession(); Transaction tx = null; try { tx = s.beginTransaction(); fooList = s.find( "select foo from eg.Foo foo where foo.Date = current date" // uses db2 date function ); bar = (Bar) s.create(Bar.class); tx.commit(); } catch (Exception e) { if (tx!=null) tx.rollback(); s.close(); throw e; } s.disconnect();
Позднее:
s.reconnect(); try { tx = s.beginTransaction(); bar.setFooTable( new HashMap() ); Iterator iter = fooList.iterator(); while ( iter.hasNext() ) { Foo foo = (Foo) iter.next(); s.lock(foo, LockMode.READ); // проверяем, что foo не устарел. bar.getFooTable().put( foo.getName(), foo ); } tx.commit(); } catch (Exception e) { if (tx!=null) tx.rollback(); throw e; } finally { s.close(); }
Отсюда видно, что связь между транзакциями (Transaction) и сессией Session является многие-к-одному. Сессия представляет собой взаимодействие между приложением и базой данных. Транзакция разделяет это взаимодействие на атомарные на уровне базы данных единицы работы (unit-of-work).
Здесь не подразумевается что пользователи тартят много времени на беспокойства по поводу выбора стратегий блокировки. Обычно достаточно укзать уровень изоляции для JDBC соединения и позволить базе данный выполнить всю работу. Тем не менее, продвинутые пользователи в некоторых случаях хотят применять пессимистическую стратегию блокировки, или изменять блокировки в начале новой транзакции.
Hibernate всегда используег мехнаизмы блокировки базы данных, он никогда не блокирует объекты в памяти!
Класс LockMode опредеяет различные уровни блокировки, которые могут быть использованы Hibernate. Блокировки применяются следующими механизмами:
LockMode.WRITE автоматически применяется когда Hiberante обновлет или вставляет столбец.
LockMode.UPGRADE может быть применен при явном запросе пользователя при выполении SELECT ... FOR UPDATE для баз данных, которые поддерживают такой синтаксис.
LockMode.UPGRADE_NOWAIT может быть применен при явном запросе пользователя для SELECT ... FOR UPDATE NOWAIT в Oracle.
LockMode.READ применяется автоматически когда Hibernate читает данные под уровнями изоляции Repeatable Read или Serializable. Может быть переопределен явным запросом пользователя.
LockMode.NONE представляет отсутсвие блокировки. Все объекты переключаются в этот режим блокировки в конце транзакции. Объекты ассоциированные с сессией вызовом update() или saveOrUpdate() так же в начале имеют этот режим блокировки.
"Явный запрос пользователя" может быть выражен одним из следующих способов:
Вызовом Session.load() с указанием LockMode.
Вызовом Session.lock().
Вызовом Query.setLockMode().
Если Session.load() был вызван с UPGRADE или UPGRADE_NOWAIT, и запрашиваемый объект еще не загружен в сессию объект загружается с использованием SELECT ... FOR UPDATE. Если load() был вызван для объекта который уже загружен в сессию с менее стогой блокировкой чем при запросе, Hibernate вызывает lock() для данного объекта.
Session.lock() осуществляет проверку номера версии если блокировка специфицирована как READ, UPGRADE или UPGRADE_NOWAIT. (В случае UPGRADE или UPGRADE_NOWAIT, используется SELECT ... FOR UPDATE.)
Если база данных не поддерживает запрашиваемого режима блокировки, Hibernate использует подходящий альтернативный режим (вместо инициации исключения). Это обеспечивает переносимость приложения между базами данных.
Hibernate is equiped with an extremely powerful query language that (quite intentionally) looks very much like SQL. But don't be fooled by the syntax; HQL is fully object-oriented, understanding notions like inheritence, polymorphism and association.
Queries are case-insensitive, except for names of Java classes and properties. So SeLeCT is the same as sELEct is the same as SELECT but net.sf.hibernate.eg.FOO is not net.sf.hibernate.eg.Foo and foo.barSet is not foo.BARSET.
This manual uses lowercase HQL keywords. Some users find queries with uppercase keywords more readable, but we find this convention ugly when embedded in Java code.
The simplest possible Hibernate query is of the form:
from eg.Cat
which simply returns all instances of the class eg.Cat.
Most of the time, you will need to assign an alias, since you will want to refer to the Cat in other parts of the query.
from eg.Cat as cat
This query assigns the alias cat to Cat instances, so we could use that alias later in the query. The as keyword is optional; we could also write:
from eg.Cat cat
Multiple classes may appear, resulting in a cartesian product or "cross" join.
from Formula, Parameter
from Formula as form, Parameter as param
It is considered good practice to name query aliases using an initial lowercase, consistent with Java naming standards for local variables (eg. domesticCat).
We may also assign aliases to associated entities, or even to elements of a collection of values, using a join.
from eg.Cat as cat inner join cat.mate as mate left outer join cat.kittens as kitten from eg.Cat as cat left join cat.mate.kittens as kittens from Formula form full join form.parameter param
The supported join types are borrowed from ANSI SQL
inner join
left outer join
right outer join
full join (not usually useful)
The inner join, left outer join and right outer join constructs may be abbreviated.
from eg.Cat as cat join cat.mate as mate left join cat.kittens as kitten
In addition, a "fetch" join allows associations or collections of values to be initialized along with their parent objects, using a single select. This is particularly useful in the case of a collection. It effectively overrides the outer join and lazy declarations of the mapping file for associations and collections.
from eg.Cat as cat inner join fetch cat.mate left join fetch cat.kittens
A fetch join does not usually need to assign an alias, because the associated objects should not be used in the where clause (or any other clause). Also, the associated objects are not returned directly in the query results. Instead, they may be accessed via the parent object.
Note that, in the current implementation, only one collection role may be fetched in a query (everything else would be non-performant). Note also that the fetch construct may not be used in queries called using scroll() or iterate(). Finally, note that full join fetch and right join fetch are not meaningful.
The select clause picks which objects and properties to return in the query result set. Consider:
select mate from eg.Cat as cat inner join cat.mate as mate
The query will select mates of other Cats. Actually, you may express this query more compactly as:
select cat.mate from eg.Cat cat
You may even select collection elements, using the special elements function. The following query returns all kittens of any cat.
select elements(cat.kittens) from eg.Cat cat
Queries may return properties of any value type including properties of component type:
select cat.name from eg.DomesticCat cat where cat.name like 'fri%' select cust.name.firstName from Customer as cust
Queries may return multiple objects and/or properties as an array of type Object[]
select mother, offspr, mate.name from eg.DomesticCat as mother inner join mother.mate as mate left outer join mother.kittens as offspr
or as an actual typesafe Java object
select new Family(mother, mate, offspr) from eg.DomesticCat as mother join mother.mate as mate left join mother.kittens as offspr
assuming that the class Family has an appropriate constructor.
HQL queries may even return the results of aggregate functions on properties:
select avg(cat.weight), sum(cat.weight), max(cat.weight), count(cat) from eg.Cat cat
Collections may also appear inside aggregate functions in the select clause.
select cat, count( elements(cat.kittens) ) from eg.Cat cat group by cat
The supported aggregate functions are
avg(...), sum(...), min(...), max(...)
count(*)
count(...), count(distinct ...), count(all...)
The distinct and all keywords may be used and have the same semantics as in SQL.
select distinct cat.name from eg.Cat cat select count(distinct cat.name), count(cat) from eg.Cat cat
A query like:
from eg.Cat as cat
returns instances not only of Cat, but also of subclasses like DomesticCat. Hibernate queries may name any Java class or interface in the from clause. The query will return instances of all persistent classes that extend that class or implement the interface. The following query would return all persistent objects:
from java.lang.Object o
The interface Named might be implemented by various persistent classes:
from eg.Named n, eg.Named m where n.name = m.name
Note that these last two queries will require more than one SQL SELECT. This means that the order by clause does not correctly order the whole result set. (It also means you can't call these queries using Query.scroll().)
The where clause allows you to narrow the list of instances returned.
from eg.Cat as cat where cat.name='Fritz'
returns instances of Cat named 'Fritz'.
select foo from eg.Foo foo, eg.Bar bar where foo.startDate = bar.date
will return all instances of Foo for which there exists an instance of bar with a date property equal to the startDate property of the Foo. Compound path expressions make the where clause extremely powerful. Consider:
from eg.Cat cat where cat.mate.name is not null
This query translates to an SQL query with a table (inner) join. If you were to write something like
from eg.Foo foo where foo.bar.baz.customer.address.city is not null
you would end up with a query that would require four table joins in SQL.
The = operator may be used to compare not only properties, but also instances:
from eg.Cat cat, eg.Cat rival where cat.mate = rival.mate select cat, mate from eg.Cat cat, eg.Cat mate where cat.mate = mate
The special property (lowercase) id may be used to reference the unique identifier of an object. (You may also use its property name.)
from eg.Cat as cat where cat.id = 123 from eg.Cat as cat where cat.mate.id = 69
The second query is efficient. No table join is required!
Properties of composite identifiers may also be used. Suppose Person has a composite identifier consisting of country and medicareNumber.
from bank.Person person where person.id.country = 'AU' and person.id.medicareNumber = 123456 from bank.Account account where account.owner.id.country = 'AU' and account.owner.id.medicareNumber = 123456
Once again, the second query requires no table join.
Likewise, the special property class accesses the discriminator value of an instance in the case of polymorphic persistence. A Java class name embedded in the where clause will be translated to its discriminator value.
from eg.Cat cat where cat.class = eg.DomesticCat
You may also specify properties of components or composite user types (and of components of components, etc). Never try to use a path-expression that ends in a property of component type (as opposed to a property of a component). For example, if store.owner is an entity with a component address
store.owner.address.city // okay store.owner.address // error!
An "any" type has the special properties id and class, allowing us to express a join in the following way (where AuditLog.item is a property mapped with <any>).
from eg.AuditLog log, eg.Payment payment where log.item.class = 'eg.Payment' and log.item.id = payment.id
Notice that log.item.class and payment.class would refer to the values of completely different database columns in the above query.
Expressions allowed in the where clause include most of the kind of things you could write in SQL:
mathematical operators +, -, *, /
binary comparison operators =, >=, <=, <>, !=, like
logical operations and, or, not
string concatenation ||
SQL scalar functions like upper() and lower()
Parentheses ( ) indicate grouping
in, between, is null
JDBC IN parameters ?
named parameters :name, :start_date, :x1
SQL literals 'foo', 69, '1970-01-01 10:00:01.0'
Java public static final constants eg.Color.TABBY
in and between may be used as follows:
from eg.DomesticCat cat where cat.name between 'A' and 'B' from eg.DomesticCat cat where cat.name in ( 'Foo', 'Bar', 'Baz' )
and the negated forms may be written
from eg.DomesticCat cat where cat.name not between 'A' and 'B' from eg.DomesticCat cat where cat.name not in ( 'Foo', 'Bar', 'Baz' )
Likewise, is null and is not null may be used to test for null values.
Booleans may be easily used in expressions by declaring HQL query substitutions in Hibernate configuration:
<property name="hibernate.query.substitutions">true 1, false 0</property>
This will replace the keywords true and false with the literals 1 and 0 in the translated SQL from this HQL:
from eg.Cat cat where cat.alive = true
You may test the size of a collection with the special property size, or the special size() function.
from eg.Cat cat where cat.kittens.size > 0 from eg.Cat cat where size(cat.kittens) > 0
For indexed collections, you may refer to the minimum and maximum indices using minIndex and maxIndex. Similarly, you may refer to the minimum and maximum elements of a collection of basic type using minElement and maxElement.
from Calendar cal where cal.holidays.maxElement > current date
There are also functional forms (which, unlike the constructs above, are not case sensitive):
from Order order where maxindex(order.items) > 100 from Order order where minelement(order.items) > 10000
The SQL functions any, some, all, exists, in are supported when passed the element or index set of a collection (elements and indices functions) or the result of a subquery (see below).
select mother from eg.Cat as mother, eg.Cat as kit where kit in elements(foo.kittens) select p from eg.NameList list, eg.Person p where p.name = some elements(list.names) from eg.Cat cat where exists elements(cat.kittens) from eg.Player p where 3 > all elements(p.scores) from eg.Show show where 'fizard' in indices(show.acts)
Note that these constructs - size, elements, indices, minIndex, maxIndex, minElement, maxElement - have certain usage restrictions:
in a where clause: only for databases with subselects
in a select clause: only elements and indices make sense
Elements of indexed collections (arrays, lists, maps) may be referred to by index (in a where clause only):
from Order order where order.items[0].id = 1234 select person from Person person, Calendar calendar where calendar.holidays['national day'] = person.birthDay and person.nationality.calendar = calendar select item from Item item, Order order where order.items[ order.deliveredItemIndices[0] ] = item and order.id = 11 select item from Item item, Order order where order.items[ maxindex(order.items) ] = item and order.id = 11
The expression inside [] may even be an arithmetic expression.
select item from Item item, Order order where order.items[ size(order.items) - 1 ] = item
HQL also provides the built-in index() function, for elements of a one-to-many association or collection of values.
select item, index(item) from Order order join order.items item where index(item) < 5
Scalar SQL functions supported by the underlying database may be used
from eg.DomesticCat cat where upper(cat.name) like 'FRI%'
If you are not yet convinced by all this, think how much longer and less readable the following query would be in SQL:
select cust from Product prod, Store store inner join store.customers cust where prod.name = 'widget' and store.location.name in ( 'Melbourne', 'Sydney' ) and prod = all elements(cust.currentOrder.lineItems)
Hint: something like
SELECT cust.name, cust.address, cust.phone, cust.id, cust.current_order FROM customers cust, stores store, locations loc, store_customers sc, product prod WHERE prod.name = 'widget' AND store.loc_id = loc.id AND loc.name IN ( 'Melbourne', 'Sydney' ) AND sc.store_id = store.id AND sc.cust_id = cust.id AND prod.id = ALL( SELECT item.prod_id FROM line_items item, orders o WHERE item.order_id = o.id AND cust.current_order = o.id )
The list returned by a query may be ordered by any property of a returned class or components:
from eg.DomesticCat cat order by cat.name asc, cat.weight desc, cat.birthdate
The optional asc or desc indicate ascending or descending order respectively.
A query that returns aggregate values may be grouped by any property of a returned class or components:
select cat.color, sum(cat.weight), count(cat) from eg.Cat cat group by cat.color select foo.id, avg( elements(foo.names) ), max( indices(foo.names) ) from eg.Foo foo group by foo.id
Note: You may use the elements and indices constructs inside a select clause, even on databases with no subselects.
A having clause is also allowed.
select cat.color, sum(cat.weight), count(cat) from eg.Cat cat group by cat.color having cat.color in (eg.Color.TABBY, eg.Color.BLACK)
SQL functions and aggregate functions are allowed in the having and order by clauses, if supported by the underlying database (ie. not in MySQL).
select cat from eg.Cat cat join cat.kittens kitten group by cat having avg(kitten.weight) > 100 order by count(kitten) asc, sum(kitten.weight) desc
Note that neither the group by clause nor the order by clause may contain arithmetic expressions.
For databases that support subselects, Hibernate supports subqueries within queries. A subquery must be surrounded by parentheses (often by an SQL aggregate function call). Even correlated subqueries (subqueries that refer to an alias in the outer query) are allowed.
from eg.Cat as fatcat where fatcat.weight > ( select avg(cat.weight) from eg.DomesticCat cat ) from eg.DomesticCat as cat where cat.name = some ( select name.nickName from eg.Name as name ) from eg.Cat as cat where not exists ( from eg.Cat as mate where mate.mate = cat ) from eg.DomesticCat as cat where cat.name not in ( select name.nickName from eg.Name as name )
Hibernate queries can be quite powerful and complex. In fact, the power of the query language is one of Hibernate's main selling points. Here are some example queries very similar to queries that I used on a recent project. Note that most queries you will write are much simpler than these!
The following query returns the order id, number of items and total value of the order for all unpaid orders for a particular customer and given minimum total value, ordering the results by total value. In determining the prices, it uses the current catalog. The resulting SQL query, against the ORDER, ORDER_LINE, PRODUCT, CATALOG and PRICE tables has four inner joins and an (uncorrelated) subselect.
select order.id, sum(price.amount), count(item) from Order as order join order.lineItems as item join item.product as product, Catalog as catalog join catalog.prices as price where order.paid = false and order.customer = :customer and price.product = product and catalog.effectiveDate < sysdate and catalog.effectiveDate >= all ( select cat.effectiveDate from Catalog as cat where cat.effectiveDate < sysdate ) group by order having sum(price.amount) > :minAmount order by sum(price.amount) desc
What a monster! Actually, in real life, I'm not very keen on subqueries, so my query was really more like this:
select order.id, sum(price.amount), count(item) from Order as order join order.lineItems as item join item.product as product, Catalog as catalog join catalog.prices as price where order.paid = false and order.customer = :customer and price.product = product and catalog = :currentCatalog group by order having sum(price.amount) > :minAmount order by sum(price.amount) desc
The next query counts the number of payments in each status, excluding all payments in the AWAITING_APPROVAL status where the most recent status change was made by the current user. It translates to an SQL query with two inner joins and a correlated subselect against the PAYMENT, PAYMENT_STATUS and PAYMENT_STATUS_CHANGE tables.
select count(payment), status.name from Payment as payment join payment.currentStatus as status join payment.statusChanges as statusChange where payment.status.name <> PaymentStatus.AWAITING_APPROVAL or ( statusChange.timeStamp = ( select max(change.timeStamp) from PaymentStatusChange change where change.payment = payment ) and statusChange.user <> :currentUser ) group by status.name, status.sortOrder order by status.sortOrder
If I would have mapped the statusChanges collection as a list, instead of a set, the query would have been much simpler to write.
select count(payment), status.name from Payment as payment join payment.currentStatus as status where payment.status.name <> PaymentStatus.AWAITING_APPROVAL or payment.statusChanges[ maxIndex(payment.statusChanges) ].user <> :currentUser group by status.name, status.sortOrder order by status.sortOrder
The next query uses the MS SQL Server isNull() function to return all the accounts and unpaid payments for the organization to which the current user belongs. It translates to an SQL query with three inner joins, an outer join and a subselect against the ACCOUNT, PAYMENT, PAYMENT_STATUS, ACCOUNT_TYPE, ORGANIZATION and ORG_USER tables.
select account, payment from Account as account left outer join account.payments as payment where :currentUser in elements(account.holder.users) and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID) order by account.type.sortOrder, account.accountNumber, payment.dueDate
For some databases, we would need to do away with the (correlated) subselect.
select account, payment from Account as account join account.holder.users as user left outer join account.payments as payment where :currentUser = user and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID) order by account.type.sortOrder, account.accountNumber, payment.dueDate
You can count the number of query results without actually returning them:
( (Integer) session.iterate("select count(*) from ....").next() ).intValue()
To order a result by the size of a collection, use the following query:
select usr.id, usr.name from User as usr left join usr.messages as msg group by usr.id, usr.name order by count(msg)
If your database supports subselects, you can place a condition upon selection size in the where clause of your query:
from User usr where size(usr.messages) >= 1
If your database doesn't support subselects, use the following query:
select usr.id, usr.name from User usr.name join usr.messages msg group by usr.id, usr.name having count(msg) >= 1
As this solution can't return a User with zero messages because of the inner join, the following form is also useful:
select usr.id, usr.name from User as usr left join usr.messages as msg group by usr.id, usr.name having count(msg) = 0
Properties of a JavaBean can be bound to named query parameters:
Query q = s.createQuery("from foo in class Foo where foo.name=:name and foo.size=:size"); q.setProperties(fooBean); // fooBean has getName() and getSize() List foos = q.list();
Collections are pageable by using the Query interface with a filter:
Query q = s.createFilter( collection, "" ); // the trivial filter q.setMaxResults(PAGE_SIZE); q.setFirstResult(PAGE_SIZE * pageNumber); List page = q.list();
Collection elements may be ordered or grouped using a query filter:
Collection orderedCollection = s.filter( collection, "order by this.amount" ); Collection counts = s.filter( collection, "select this.type, count(this) group by this.type" );
You can find the size of a collection without initializing it:
( (Integer) session.iterate("select count(*) from ....").next() ).intValue();
В Hibernate существует интуитивный и наращиваемый API для критериальных запросов. Сейчас данный API уступает в мощности более зрелым возможностям HQL запросов. В частности, критериальные запросы не поддерживают проекции (projection) и агрегации.
Интерфейс net.sf.hibernate.Criteria представляет запрос по заданному персистентному классу. Фабрикой для создания экземляров Criteria является Session.
Criteria crit = sess.createCriteria(Cat.class); crit.setMaxResults(50); List cats = crit.list();
Индивидуальным критерионом (criterion) является экземпляр интерфейса net.sf.hibernate.expression.Criterion. Класс net.sf.hibernate.expression.Expression определяющий фабричные методы для получения определенных встроеных типов Criterion.
List cats = sess.createCriteria(Cat.class) .add( Expression.like("name", "Fritz%") ) .add( Expression.between("weight", minWeight, maxWeight) ) .list();
Выражения (expressions) могут быть логически сгрупированны
List cats = sess.createCriteria(Cat.class) .add( Expression.like("name", "Fritz%") ) .add( Expression.or( Expression.eq( "age", new Integer(0) ), Expression.isNull("age") ) ) .list();
List cats = sess.createCriteria(Cat.class) .add( Expression.in( "name", new String[] { "Fritz", "Izi", "Pk" } ) ) .add( Expression.disjunction() .add( Expression.isNull("age") ) .add( Expression.eq("age", new Integer(0) ) ) .add( Expression.eq("age", new Integer(1) ) ) .add( Expression.eq("age", new Integer(2) ) ) ) ) .list();
Существует множество типов критерионов (criterion) (подклассы Expression), но с помощью одного из них возможно задавать SQL напрямую.
List cats = sess.createCriteria(Cat.class) .add( Expression.sql("lower({alias}.name) like lower(?)", "Fritz%", Hibernate.STRING) ) .list();
Вместо {alias} будет подставлено значение синонима запрашиваемой сущности.
Вы можете отсортировать результаты при помощи net.sf.hibernate.expression.Order
List cats = sess.createCriteria(Cat.class) .add( Expression.like("name", "F%") .addOrder( Order.asc("name") ) .addOrder( Order.desc("age") ) .setMaxResults(50) .list();
Вы можете легко специфицировать ограничения для связанных сущюностей используя createCriteria() для навигации по ассоциациям.
List cats = sess.createCriteria(Cat.class) .add( Expression.like("name", "F%") .createCriteria("kittens") .add( Expression.like("name", "F%") .list();
Учтите, что второй вызов createCriteria() вернет новый экземляр Criteria, который будет укзывать на элемент коллекции kittens.
В определенных случаях используется альтернативная форма (см. ниже).
List cats = sess.createCriteria(Cat.class) .createAlias("kittens", "kt") .createAlias("mate", "mt") .add( Expression.eqProperty("kt.name", "mt.name") ) .list();
(createAlias() не создает нового экземпляра Criteria.)
Учтите, что коллекция kittens содержится в экземплярах объекта Cat возвращаемая предыдущими двумя запросами не фильтруется критериями! Если вам нужно получить только те элементы kittens которые соответсвуют критерию, вы должны использовать returnMaps().
List cats = sess.createCriteria(Cat.class) .createCriteria("kittens", "kt") .add( Expression.eq("name", "F%") ) .returnMaps() .list(); Iterator iter = cats.iterator(); while ( iter.hasNext() ) { Map map = (Map) iter.next(); Cat cat = (Cat) map.get(Criteria.ROOT_ALIAS); Cat kitten = (Cat) map.get("kt"); }
Вы можете специфицировать семантику выборки данных по ассоциациям во время испольнения используя setFetchMode().
List cats = sess.createCriteria(Cat.class) .add( Expression.like("name", "Fritz%") ) .setFetchMode("mate", FetchMode.EAGER) .setFetchMode("kittens", FetchMode.EAGER) .list();
Этот запрос будет получать mate и kittens используя outer join.
Класс net.sf.hibernate.expression.Example позволяет вам конструировать критерионы (criterion) запросов из данных заданного экземпляра класса.
Cat cat = new Cat(); cat.setSex('F'); cat.setColor(Color.BLACK); List results = session.createCriteria(Cat.class) .add( Example.create(cat) ) .list();
Свойства версии, идентифицаторы и ассоциации игнорируются. По умолчанию, параметры содержащие null значения так же исключаются из сконструированного запроса.
Вы можете настраивать правила работы Example.
Example example = Example.create(cat) .excludeZeroes() //исключает свойства с нулевыми значениями .excludeProperty("color") //исключает своство "color" .ignoreCase() //задает независимое от регистра сравнение строк .enableLike(); //использует like для сравнения строк List results = session.createCriteria(Cat.class) .add(example) .list();
Вы можете так же использовать примеры для задания критериев ассоциированных объектов.
List results = session.createCriteria(Cat.class) .add( Example.create(cat) ) .createCriteria("mate") .add( Example.create( cat.getMate() ) ) .list();
Вы можете так же выражать запросы на родном для ващей базы данных диалекте SQL. Это полезно если вы хотите использовать специфичные возможности такие как ключевое слово CONNECT в Oracle. Это так же предусматривает простой путь переноса приложений написаных с использованием SQL/JDBC на Hibernate.
SQL запросы преставляются через тот же Query интерфейс, который используется для HQL запросов. Единствоенное различие заключается в том, что для SQL используется метод Session.createSQLQuery().
Query sqlQuery = sess.createSQLQuery("select {cat.*} from cats {cat}", "cat", Cat.class); sqlQuery.setMaxResults(50); List cats = sqlQuery.list();
Три параметра используемые при вызове createSQLQuery():
строка SQL запроса
название алиаса таблицы
возвращаемый запросом персистентный класс
Название алиаса используется в строке SQL запроса для обращений к свойствам замапленного класса (в данном примере это Cat). Вы можете получить множество объектов в одной строке передавая масив строк (String) для наименований алиасов и массив объектов Class соотвествующих классов.
Нотация {cat.*} использованная в примере выше является сокращением для "все свойства". Вы можете так же указать список свойств явно, но вы должны доверить Hibernate выбор алиасов для свойств. Заменой для таких алиасов являются название свойств с указанием алиаса таблиц для каждого свойства. В следующем примере мы получаем котов (Cat) из таблицы (cat_log) отличной от декларированной в метаданных маппинга. Обратите внимание на то, как используются алиасы свойств в выражении where.
String sql = "select cat.originalId as {cat.id}, " + " cat.mateid as {cat.mate}, cat.sex as {cat.sex}, " + " cat.weight*10 as {cat.weight}, cat.name as {cat.name}" + " from cat_log cat where {cat.mate} = :catId" List loggedCats = sess.createSQLQuery(sql, "cat", Cat.class) .setLong("catId", catId) .list();
Замечание: если вы перечисляете свойства явно, вы должны указать все свойства класса и дочерних к нему классов!
Именованные SQL запросы могут быть определены в документе маппинга и вызваны в точности так же, как это осуществляется для HQL запросов.
List people = sess.getNamedQuery("mySqlQuery") .setMaxResults(50) .list();
<sql-query name="mySqlQuery"> <return alias="person" class="eg.Person"/> SELECT {person}.NAME AS {person.name}, {person}.AGE AS {person.age}, {person}.SEX AS {person.sex} FROM PERSON {person} WHERE {person}.NAME LIKE 'Hiber%' </sql-query>
We've already spent quite some time talking about collections. In this section we will highlight a couple more issues about how collections behave at runtime.
Hibernate defines three basic kinds of collections:
collections of values
one to many associations
many to many associations
This classification distinguishes the various table and foreign key relationships but does not tell us quite everything we need to know about the relational model. To fully understand the relational structure and performance characteristics, we must also consider the structure of the primary key that is used by Hibernate to update or delete collection rows. This suggests the following classification:
indexed collections
sets
bags
All indexed collections (maps, lists, arrays) have a primary key consisting of the <key> and <index> columns. In this case collection updates are usually extremely efficient - the primary key may be efficiently indexed and a particular row may be efficiently located when Hibernate tries to update or delete it.
Sets have a primary key consisting of <key> and element columns. This may be less efficient for some types of collection element, particularly composite elements or large text or binary fields; the database may not be able to index a complex primary key as efficently. On the other hand, for one to many or many to many associations, particularly in the case of synthetic identifiers, it is likely to be just as efficient. (Side-note: if you want SchemaExport to actually create the primary key of a <set> for you, you must declare all columns as not-null="true".)
Bags are the worst case. Since a bag permits duplicate element values and has no index column, no primary key may be defined. Hibernate has no way of distinguishing between duplicate rows. Hibernate resolves this problem by completely removing (in a single DELETE) and recreating the collection whenever it changes. This might be very inefficient.
Note that for a one-to-many association, the "primary key" may not be the physical primary key of the database table - but even in this case, the above classification is still useful. (It still reflects how Hibernate "locates" individual rows of the collection.)
From the discussion above, it should be clear that indexed collections and (usually) sets allow the most efficient operation in terms of adding, removing and updating elements.
There is, arguably, one more advantage that indexed collections have over sets for many to many associations or collections of values. Because of the structure of a Set, Hibernate doesn't ever UPDATE a row when an element is "changed". Changes to a Set always work via INSERT and DELETE (of individual rows). Once again, this consideration does not apply to one to many associations.
After observing that arrays cannot be lazy, we would conclude that lists, maps and sets are the most performant collection types. (With the caveat that a set might be less efficient for some collections of values.)
Sets are expected to be the most common kind of collection in Hibernate applications.
There is an undocumented feature in this release of Hibernate. The <idbag> mapping implements bag semantics for a collection of values or a many to many association and is more efficient that any other style of collection in this case!
Just before you ditch bags forever, there is a particular case in which bags (and also lists) are much more performant than sets. For a collection with inverse="true" (the standard bidirectional one-to-many relationship idiom, for example) we can add elements to a bag or list without needing to initialize (fetch) the bag elements! This is because Collection.add() or Collection.addAll() must always return true for a bag or List (unlike a Set). This can make the following common code much faster.
Parent p = (Parent) sess.load(Parent.class, id); Child c = new Child(); c.setParent(p); p.getChildren().add(c); //no need to fetch the collection! sess.flush();
Occasionally, deleting collection elements one by one can be extremely inefficient. Hibernate isn't completly stupid, so it knows not to do that in the case of an newly-empty collection (if you called list.clear(), for example). In this case, Hibernate will issue a single DELETE and we are done!
Suppose we add a single element to a collection of size twenty and then remove two elements. Hibernate will issue one INSERT statement and two DELETE statements (unless the collection is a bag). This is certainly desirable.
However, suppose that we remove eighteen elements, leaving two and then add thee new elements. There are two possible ways to proceed
delete eighteen rows one by one and then insert three rows
remove the whole collection (in one SQL DELETE) and insert all five current elements (one by one)
Hibernate isn't smart enough to know that the second option is probably quicker in this case. (And it would probably be undesirable for Hibernate to be that smart; such behaviour might confuse database triggers, etc.)
Fortunately, you can force this behaviour (ie. the second strategy) at any time by discarding (ie. dereferencing) the original collection and returning a newly instantiated collection with all the current elements. This can be very useful and powerful from time to time.
We have already shown how you can use lazy initialization for persistent collections in the chapter about collection mappings. A similar effect is achievable for ordinary object references, using CGLIB proxies. We have also mentioned how Hibernate caches persistent objects at the level of a Session. More aggressive caching strategies may be configured upon a class-by-class basis.
In the next section, we show you how to use these features, which may be used to achieve much higher performance, where necessary.
Hibernate implements lazy initializing proxies for persistent objects using runtime bytecode enhancement (via the excellent CGLIB library).
The mapping file declares a class or interface to use as the proxy interface for that class. The recommended approach is to specify the class itself:
<class name="eg.Order" proxy="eg.Order">
The runtime type of the proxies will be a subclass of Order. Note that the proxied class must implement a default constructor with at least package visibility.
There are some gotchas to be aware of when extending this approach to polymorphic classes, eg.
<class name="eg.Cat" proxy="eg.Cat"> ...... <subclass name="eg.DomesticCat" proxy="eg.DomesticCat"> ..... </subclass> </class>
Firstly, instances of Cat will never be castable to DomesticCat, even if the underlying instance is an instance of DomesticCat.
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a proxy (does not hit the db) if ( cat.isDomesticCat() ) { // hit the db to initialize the proxy DomesticCat dc = (DomesticCat) cat; // Error! .... }
Secondly, it is possible to break proxy ==.
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a Cat proxy DomesticCat dc = (DomesticCat) session.load(DomesticCat.class, id); // required new DomesticCat proxy! System.out.println(cat==dc); // false
However, the situation is not quite as bad as it looks. Even though we now have two references to different proxy objects, the underlying instance will still be the same object:
cat.setWeight(11.0); // hit the db to initialize the proxy System.out.println( dc.getWeight() ); // 11.0
Third, you may not use a CGLIB proxy for a final class or a class with any final methods.
Finally, if your persistent object acquires any resources upon instantiation (eg. in initializers or default constructor), then those resources will also be acquired by the proxy. The proxy class is an actual subclass of the persistent class.
These problems are all due to fundamental limitations in Java's single inheritence model. If you wish to avoid these problems your persistent classes must each implement an interface that declares its business methods. You should specify these interfaces in the mapping file. eg.
<class name="eg.Cat" proxy="eg.ICat"> ...... <subclass name="eg.DomesticCat" proxy="eg.IDomesticCat"> ..... </subclass> </class>
where Cat implements the interface ICat and DomesticCat implements the interface IDomesticCat. Then proxies for instances of Cat and DomesticCat may be returned by load() or iterate(). (Note that find() does not return proxies.)
ICat cat = (ICat) session.load(Cat.class, catid); Iterator iter = session.iterate("from cat in class eg.Cat where cat.name='fritz'"); ICat fritz = (ICat) iter.next();
Relationships are also lazily initialized. This means you must declare any properties to be of type ICat, not Cat.
Certain operations do not require proxy initialization
equals(), if the persistent class does not override equals()
hashCode(), if the persistent class does not override hashCode()
The identifier getter method
Hibernate will detect persistent classes that override equals() or hashCode().
Exceptions that occur while initializing a proxy are wrapped in a LazyInitializationException.
Sometimes we need to ensure that a proxy or collection is initialized before closing the Session. Of course, we can alway force initialization by calling cat.getSex() or cat.getKittens().size(), for example. But that is confusing to readers of the code and is not convenient for generic code. The static methods Hibernate.initialize() and Hibernate.isInitialized() provide the application with a convenient way of working with lazyily initialized collections or proxies. Hibernate.initialize(cat) will force the initialization of a proxy, cat, as long as its Session is still open. Hibernate.initialize( cat.getKittens() ) has a similar effect for the collection of kittens.
A Hibernate Session is a transaction-level cache of persistent data. It is possible to configure a cluster or JVM-level (SessionFactory-level) cache on a class-by-class and collection-by-collection basis. You may even plug in a clustered cache. Be careful. Caches are never aware of changes made to the persistent store by another application (though they may be configured to regularly expire cached data).
By default, Hibernate uses EHCache for JVM-level caching. (JCS support is now deprecated and will be removed in a future version of Hibernate.) You may choose a different implementation by specifying the name of a class that implements net.sf.hibernate.cache.CacheProvider using the property hibernate.cache.provider_class.
Таблица 14.1. Cache Providers
Cache | Provider class | Type | Cluster Safe | Query Cache Supported |
---|---|---|---|---|
Hashtable (not intended for production use) | net.sf.hibernate.cache.HashtableCacheProvider | memory | yes | |
EHCache | net.sf.ehcache.hibernate.Provider | memory, disk | yes | |
OSCache | net.sf.hibernate.cache.OSCacheProvider | memory, disk | yes | |
SwarmCache | net.sf.hibernate.cache.SwarmCacheProvider | clustered (ip multicast) | yes (clustered invalidation) | |
JBoss TreeCache | net.sf.hibernate.cache.TreeCacheProvider | clustered (ip multicast), transactional | yes (replication) |
The <cache> element of a class or collection mapping has the following form:
<cache
usage="transactional|read-write|nonstrict-read-write|read-only" (1)
/>
(1) | usage specifies the caching strategy: transactional, read-write, nonstrict-read-write or read-only |
Alternatively (preferrably?), you may specify <class-cache> and <collection-cache> elements in hibernate.cfg.xml.
The usage attribute specifies a cache concurrency strategy.
If your application needs to read but never modify instances of a persistent class, a read-only cache may be used. This is the simplest and best performing strategy. Its even perfectly safe for use in a cluster.
<class name="eg.Immutable" mutable="false"> <cache usage="read-only"/> .... </class>
If the application needs to update data, a read-write cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_class, naming a strategy for obtaining the JTA TransactionManager. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called. If you wish to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do not.
<class name="eg.Cat" .... > <cache usage="read-write"/> .... <set name="kittens" ... > <cache usage="read-write"/> .... </set> </class>
If the application only occasionally needs to update data (ie. if it is extremely unlikely that two transactions would try to update the same item simultaneously) and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you must specify hibernate.transaction.manager_lookup_class. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called.
The transactional cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache may only be used in a JTA environment and you must specify hibernate.transaction.manager_lookup_class.
None of the cache providers support all of the cache concurrency strategies. The following table shows which providers are compatible with which concurrency strategies.
Whenever you pass an object to save(), update() or saveOrUpdate() and whenever you retrieve an object using load(), find(), iterate(), or filter(), that object is added to the internal cache of the Session. When flush() is subsequently called, the state of that object will be synchronized with the database. If you do not want this synchronization to occur or if you are processing a huge number of objects and need to manage memory efficiently, the evict() method may be used to remove the object and its collections from the cache.
Iterator cats = sess.iterate("from eg.Cat as cat"); //a huge result set while ( cats.hasNext() ) { Cat cat = (Cat) iter.next(); doSomethingWithACat(cat); sess.evict(cat); }
Hibernate will evict associated entities automatically if the association is mapped with cascade="all" or cascade="all-delete-orphan".
The Session also provides a contains() method to determine if an instance belongs to the session cache.
To completely evict all objects from the session cache, call Session.clear()
For the second-level cache, there are methods defined on SessionFactory for evicting the cached state of an instance, entire class, collection instance or entire collection role.
Query result sets may also be cached. This is only useful for queries that are run frequently with the same parameters. To use the query cache you must first enable it by setting the property hibernate.cache.use_query_cache=true. This causes the creation of two cache regions - one holding cached query result sets (net.sf.hibernate.cache.QueryCache), the other holding timestamps of most recent updates to queried tables (net.sf.hibernate.cache.UpdateTimestampsCache). Note that the query cache does not cache the state of any entities in the result set; it caches only identifier values and results of value type. So the query cache is usually used in conjunction with the second-level cache.
Most queries do not benefit from caching, so by default queries are not cached. To enable caching, call Query.setCacheable(true). This call allows the query to look for existing cache results or add its results to the cache when it is executed.
If you require fine-grained control over query cache expiration policies, you may specify a named cache region for a particular query by calling Query.setCacheRegion().
List blogs = sess.createQuery("from Blog blog where blog.blogger = :blogger") .setEntity("blogger", blogger) .setMaxResults(15) .setCacheable(true) .setCacheRegion("frontpages") .list();
Roundtrip engineering with Hibernate is possible using a set of commandline tools maintained as part of the Hibernate project, along with Hibernate support built into XDoclet, Middlegen and AndroMDA.
The Hibernate main package comes bundled with the most important tool (it can even be used from "inside" Hibernate on-the-fly):
DDL schema generation from a mapping file (aka SchemaExport, hbm2ddl)
Other tools directly provided by the Hibernate project are delivered with a separate package, Hibernate Extensions. This package includes tools for the following tasks:
Java source generation from a mapping file (aka CodeGenerator, hbm2java)
mapping file generation from compiled Java classes or from Java source with XDoclet markup (aka MapGenerator, class2hbm)
There's actually another utitily living in Hibernate Extensions: ddl2hbm. It is considered deprecated and will no longer be maintained, Middlegen does a better job for the same task.
Third party tools with Hibernate support are:
Middlegen (mapping file generation from an existing database schema)
AndroMDA (MDA (Model-Driven Architecture) approach generating code for persistent classes from UML diagrams and their XML/XMI representation)
These 3rd party tools are not documented in this reference. Please refer to the Hibernate website for up-to-date information (a snapshot of the site is included in the Hibernate main package).
DDL may be generated from your mapping files by a command line utility. A batch file is located in the hibernate-x.x.x/bin directory of the core Hibernate package.
The generated schema include referential integrity constraints (primary and foreign keys) for entity and collection tables. Tables and sequences are also created for mapped identifier generators.
You must specify a SQL Dialect via the hibernate.dialect property when using this tool.
Many Hibernate mapping elements define an optional attribute named length. You may set the length of a column with this attribute. (Or, for numeric/decimal data types, the precision.)
Some tags also accept a not-null attribute (for generating a NOT NULL constraint on table columns) and a unique attribute (for generating UNIQUE constraint on table columns).
Some tags accept an index attribute for specifying the name of an index for that column. A unique-key attribute can be used to group columns in a single unit key constraint. Currently, the specified value of the unique-key attribute is not used to name the constraint, only to group the columns in the mapping file.
Examples:
<property name="foo" type="string" length="64" not-null="true"/> <many-to-one name="bar" foreign-key="fk_foo_bar" not-null="true"/> <element column="serial_number" type="long" not-null="true" unique="true"/>
Alternatively, these elements also accept a child <column> element. This is particularly useful for multi-column types:
<property name="foo" type="string"> <column name="foo" length="64" not-null="true" sql-type="text"/> </property> <property name="bar" type="my.customtypes.MultiColumnType"/> <column name="fee" not-null="true" index="bar_idx"/> <column name="fi" not-null="true" index="bar_idx"/> <column name="fo" not-null="true" index="bar_idx"/> </property>
The sql-type attribute allows the user to override the default mapping of Hibernate type to SQL datatype.
The check attribute allows you to specify a check constraint.
<property name="foo" type="integer"> <column name="foo" check="foo > 10"/> </property> <class name="Foo" table="foos" check="bar < 100.0"> ... <property name="bar" type="float"/> </class>
Таблица 15.1. Summary
Attribute | Values | Interpretation |
---|---|---|
length | number | column length/decimal precision |
not-null | true|false | specfies that the column should be non-nullable |
unique | true|false | specifies that the column should have a unique constraint |
index | index_name | specifies the name of a (multi-column) index |
unique-key | unique_key_name | specifies the name of a multi-column unique constraint |
foreign-key | foreign_key_name | specifies the name of the foreign key constraint generated for an association |
sql-type | column_type | overrides the default column type (attribute of <column> element only) |
check | SQL expression | create an SQL check constraint on either column or table |
The SchemaExport tool writes a DDL script to standard out and/or executes the DDL statements.
java -cp hibernate_classpaths net.sf.hibernate.tool.hbm2ddl.SchemaExport options mapping_files
Таблица 15.2. SchemaExport Command Line Options
Option | Description |
---|---|
--quiet | don't output the script to stdout |
--drop | only drop the tables |
--text | don't export to the database |
--output=my_schema.ddl | output the ddl script to a file |
--config=hibernate.cfg.xml | read Hibernate configuration from an XML file |
--properties=hibernate.properties | read database properties from a file |
--format | format the generated SQL nicely in the script |
--delimiter=x | set an end of line delimiter for the script |
You may even embed SchemaExport in your application:
Configuration cfg = ....; new SchemaExport(cfg).create(false, true);
Database properties may be specified
as system properties with -D<property>
in hibernate.properties
in a named properties file with --properties
The needed properties are:
You can call SchemaExport from your Ant build script:
<target name="schemaexport"> <taskdef name="schemaexport" classname="net.sf.hibernate.tool.hbm2ddl.SchemaExportTask" classpathref="class.path"/> <schemaexport properties="hibernate.properties" quiet="no" text="no" drop="no" delimiter=";" output="schema-export.sql"> <fileset dir="src"> <include name="**/*.hbm.xml"/> </fileset> </schemaexport> </target>
The SchemaUpdate tool will update an existing schema with "incremental" changes. Note that SchemaUpdate depends heavily upon the JDBC metadata API, so it will not work with all JDBC drivers.
java -cp hibernate_classpaths net.sf.hibernate.tool.hbm2ddl.SchemaUpdate options mapping_files
Таблица 15.4. SchemaUpdate Command Line Options
Option | Description |
---|---|
--quiet | don't output the script to stdout |
--properties=hibernate.properties | read database properties from a file |
You may embed SchemaUpdate in your application:
Configuration cfg = ....; new SchemaUpdate(cfg).execute(false);
You can call SchemaUpdate from the Ant script:
<target name="schemaupdate"> <taskdef name="schemaupdate" classname="net.sf.hibernate.tool.hbm2ddl.SchemaUpdateTask" classpathref="class.path"/> <schemaupdate properties="hibernate.properties" quiet="no"> <fileset dir="src"> <include name="**/*.hbm.xml"/> </fileset> </schemaupdate> </target>
The Hibernate code generator may be used to generate skeletal Java implementation classes from a Hibernate mapping file. This tool is included in the Hibernate Extensions package (a seperate download).
hbm2java parses the mapping files and generates fully working Java source files from these. Thus with hbm2java one could "just" provide the .hbm files, and then don't worry about hand-writing/coding the Java files.
java -cp hibernate_classpaths net.sf.hibernate.tool.hbm2java.CodeGenerator options mapping_files
Таблица 15.5. Code Generator Command Line Options
Option | Description |
---|---|
--output=output_dir | root directory for generated code |
--config=config_file | optional file for configuring hbm2java |
The config file provides for a way to specify multiple "renderers" for the source code and to declare <meta> attributes that is "global" in scope. See more about this in the <meta> attribute section.
<codegen> <meta attribute="implements">codegen.test.IAuditable</meta> <generate renderer="net.sf.hibernate.tool.hbm2java.BasicRenderer"/> <generate package="autofinders.only" suffix="Finder" renderer="net.sf.hibernate.tool.hbm2java.FinderRenderer"/> </codegen>
This config file declares a global meta attribute "implements" and specify two renderers, the default one (BasicRenderer) and a renderer that generates Finder's (See more in "Basic Finder generation" below).
The second renderer is provided with a package and suffix attribute.
The package attribute specifies that the generated source files from this renderer should be placed here instead of the package scope specified in the .hbm files.
The suffix attribute specifies the suffix for generated files. E.g. here a file named Foo.java would be FooFinder.java instead.
It is also possible to send down arbitrary parameters to the renders by adding <param> attributes to the <generate> elements.
hbm2java currently has support for one such parameter, namely generate-concrete-empty-classes which informs the BasicRenderer to only generate empty concrete classes that extends a base class for all your classes. The following config.xml example illustrate this feature
<codegen> <generate prefix="Base" renderer="net.sf.hibernate.tool.hbm2java.BasicRenderer"/> <generate renderer="net.sf.hibernate.tool.hbm2java.BasicRenderer"> <param name="generate-empty-concrete-classes">true</param> <param name="baseclass-prefix">Base</param> </generate> </codegen>
Notice that this config.xml configure 2 (two) renderers. One that generates the Base classes, and a second one that just generates empty concrete classes.
The <meta> tag is a simple way of annotating the hbm.xml with information, so tools have a natural place to store/read information that is not directly related to the Hibernate core.
You can use the <meta> tag to tell hbm2java to only generate "protected" setters, have classes always implement a certain set of interfaces or even have them extend a certain base class and even more.
The following example:
<class name="Person"> <meta attribute="class-description"> Javadoc for the Person class @author Frodo </meta> <meta attribute="implements">IAuditable</meta> <id name="id" type="long"> <meta attribute="scope-set">protected</meta> <generator class="increment"/> </id> <property name="name" type="string"> <meta attribute="field-description">The name of the person</meta> </property> </class>
will produce something like the following (code shortened for better understanding). Notice the Javadoc comment and the protected set methods:
// default package import java.io.Serializable; import org.apache.commons.lang.builder.EqualsBuilder; import org.apache.commons.lang.builder.HashCodeBuilder; import org.apache.commons.lang.builder.ToStringBuilder; /** * Javadoc for the Person class * @author Frodo * */ public class Person implements Serializable, IAuditable { /** identifier field */ public Long id; /** nullable persistent field */ public String name; /** full constructor */ public Person(java.lang.String name) { this.name = name; } /** default constructor */ public Person() { } public java.lang.Long getId() { return this.id; } protected void setId(java.lang.Long id) { this.id = id; } /** * The name of the person */ public java.lang.String getName() { return this.name; } public void setName(java.lang.String name) { this.name = name; } }
Таблица 15.6. Supported meta tags
Attribute | Description |
---|---|
class-description | inserted into the javadoc for classes |
field-description | inserted into the javadoc for fields/properties |
interface | If true an interface is generated instead of an class. |
implements | interface the class should implement |
extends | class the class should extend (ignored for subclasses) |
generated-class | overrule the name of the actual class generated |
scope-class | scope for class |
scope-set | scope for setter method |
scope-get | scope for getter method |
scope-field | scope for actual field |
use-in-tostring | include this property in the toString() |
implement-equals | include a equals() and hashCode() method in this class. |
use-in-equals | include this property in the equals() and hashCode() method. |
bound | add propertyChangeListener support for a property |
constrained | bound + vetoChangeListener support for a property |
gen-property | property will not be generated if false (use with care) |
property-type | Overrides the default type of property. Use this with any tag's to specify the concrete type instead of just Object. |
class-code | Extra code that will inserted at the end of the class |
extra-import | Extra import that will inserted at the end of all other imports |
finder-method | see "Basic finder generator" below |
session-method | see "Basic finder generator" below |
Attributes declared via the <meta> tag are per default "inherited" inside an hbm.xml file.
What does that mean? It means that if you e.g want to have all your classes implement IAuditable then you just add an <meta attribute="implements">IAuditable</meta> in the top of the hbm.xml file, just after <hibernate-mapping>. Now all classes defined in that hbm.xml file will implement IAuditable! (Except if a class also has an "implements" meta attribute, because local specified meta tags always overrules/replaces any inherited meta tags).
Note: This applies to all <meta>-tags. Thus it can also e.g. be used to specify that all fields should be declare protected, instead of the default private. This is done by adding <meta attribute="scope-field">protected</meta> at e.g. just under the <class> tag and all fields of that class will be protected.
To avoid having a <meta>-tag inherited then you can simply specify inherit="false" for the attribute, e.g. <meta attribute="scope-class" inherit="false">public abstract</meta> will restrict the "class-scope" to the current class, not the subclasses.
It is now possible to have hbm2java generate basic finders for Hibernate properties. This requires two things in the hbm.xml files.
The first is an indication of which fields you want to generate finders for. You indicate that with a meta block inside a property tag such as:
<property name="name" column="name" type="string"> <meta attribute="finder-method">findByName</meta> </property>
The finder method name will be the text enclosed in the meta tags.
The second is to create a config file for hbm2java of the format:
<codegen> <generate renderer="net.sf.hibernate.tool.hbm2java.BasicRenderer"/> <generate suffix="Finder" renderer="net.sf.hibernate.tool.hbm2java.FinderRenderer"/> </codegen>
And then use the param to hbm2java --config=xxx.xml where xxx.xml is the config file you just created.
An optional parameter is meta tag at the class level of the format:
<meta attribute="session-method"> com.whatever.SessionTable.getSessionTable().getSession(); </meta>
Which would be the way in which you get sessions if you use the Thread Local Session pattern (documented in the Design Patterns area of the Hibernate website).
It is now possible to use velocity as an alternative rendering mechanism. The follwing config.xml shows how to configure hbm2java to use its velocity renderer.
<codegen> <generate renderer="net.sf.hibernate.tool.hbm2java.VelocityRenderer"> <param name="template">pojo.vm</param> </generate> </codegen>
The parameter named template is a resource path to the velocity macro file you want to use. This file must be available via the classpath for hbm2java. Thus remember to add the directory where pojo.vm is located to your ant task or shell script. (The default location is ./tools/src/velocity)
Be aware that the current pojo.vm generates only the most basic parts of the java beans. It is not as complete and feature rich as the default renderer - primarily a lot of the meta tags are not supported.
A skeletal mapping file may be generated from compiled persistent classes using a command line utility called MapGenerator. This utility is part of the Hibernate Extensions package.
The Hibernate mapping generator provides a mechanism to produce mappings from compiled classes. It uses Java reflection to find properties and uses heuristics to guess an appropriate mapping from the property type. The generated mapping is intended to be a starting point only. There is no way to produce a full Hibernate mapping without extra input from the user. However, the tool does take away some of the repetitive "grunt" work involved in producing a mapping.
Classes are added to the mapping one at a time. The tool will reject classes that it judges are are not Hibernate persistable.
To be Hibernate persistable a class
must not be a primitive type
must not be an array
must not be an interface
must not be a nested class
must have a default (zero argument) constructor.
Note that interfaces and nested classes actually are persistable by Hibernate, but this would not usually be intended by the user.
MapGenerator will climb the superclass chain of all added classes attempting to add as many Hibernate persistable superclasses as possible to the same database table. The search stops as soon as a property is found that has a name appearing on a list of candidate UID names.
The default list of candidate UID property names is: uid, UID, id, ID, key, KEY, pk, PK.
Properties are discovered when there are two methods in the class, a setter and a getter, where the type of the setter's single argument is the same as the return type of the zero argument getter, and the setter returns void. Furthermore, the setter's name must start with the string set and either the getter's name starts with get or the getter's name starts with is and the type of the property is boolean. In either case, the remainder of their names must match. This matching portion is the name of the property, except that the initial character of the property name is made lower case if the second letter is lower case.
The rules for determining the database type of each property are as follows:
If the Java type is Hibernate.basic(), then the property is a simple column of that type.
For hibernate.type.Type custom types and PersistentEnum a simple column is used as well.
If the property type is an array, then a Hibernate array is used, and MapGenerator attempts to reflect on the array element type.
If the property has type java.util.List, java.util.Map, or java.util.Set, then the corresponding Hibernate types are used, but MapGenerator cannot further process the insides of these types.
If the property's type is any other class, MapGenerator defers the decision on the database representation until all classes have been processed. At this point, if the class was discovered through the superclass search described above, then the property is an many-to-one association. If the class has any properties, then it is a component. Otherwise it is serializable, or not persistable.
The tool writes XML mappings to standard out and/or to a file.
When invoking the tool you must place your compiled classes on the classpath.
java -cp hibernate_and_your_class_classpaths net.sf.hibernate.tool.class2hbm.MapGenerator options and classnames
There are two modes of operation: command line or interactive.
The interactive mode is selected by providing the single command line argument --interact. This mode provides a prompt response console. Using it you can set the UID property name for each class using the uid=XXX command where XXX is the UID property name. Other command alternatives are simply a fully qualified class name, or the command done which emits the XML and terminates.
In command line mode the arguments are the options below interspersed with fully qualified class names of the classes to be processed. Most of the options are meant to be used multiple times; each use affects subsequently added classes.
Таблица 15.7. MapGenerator Command Line Options
Option | Description |
---|---|
--quiet | don't output the O-R Mapping to stdout |
--setUID=uid | set the list of candidate UIDs to the singleton uid |
--addUID=uid | add uid to the front of the list of candidate UIDs |
--select=mode | mode use select mode mode(e.g., distinct or all) for subsequently added classes |
--depth=<small-int> | limit the depth of component data recursion for subsequently added classes |
--output=my_mapping.xml | output the O-R Mapping to a file |
full.class.Name | add the class to the mapping |
--abstract=full.class.Name | see below |
The abstract switch directs the map generator tool to ignore specific super classes so that classes with common inheritance are not mapped to one large table. For instance, consider these class hierarchies:
Animal-->Mammal-->Human
Animal-->Mammal-->Marsupial-->Kangaroo
If the --abstractswitch is not used, all classes will be mapped as subclasses of Animal, resulting in one large table containing all the properties of all the classes plus a discriminator column to indicate which subclass is actually stored. If Mammal is marked as abstract, Human and Marsupial will be mapped to separate <class> declarations and stored in separate tables. Kangaroo will still be a subclass of Marsupial unless Marsupial is also marked as abstract.
One of the very first things that new users try to do with Hibernate is to model a parent / child type relationship. There are two different approaches to this. For various reasons the most convenient approach, especially for new users, is to model both Parent and Child as entity classes with a <one-to-many> association from Parent to Child. (The alternative approach is to declare the Child as a <composite-element>.) Now, it turns out that default semantics of a one to many association (in Hibernate) are much less close to the usual semantics of a parent / child relationship than those of a composite element mapping. We will explain how to use a bidirectional one to many association with cascades to model a parent / child relationship efficiently and elegantly. It's not at all difficult!
Hibernate collections are considered to be a logical part of their owning entity; never of the contained entities. This is a crucial distinction! It has the following consequences:
When we remove / add an object from / to a collection, the version number of the collection owner is incremented.
If an object that was removed from a collection is an instance of a value type (eg, a composite element), that object will cease to be persistent and its state will be completely removed from the database. Likewise, adding a value type instance to the collection will cause its state to be immediately persistent.
On the other hand, if an entity is removed from a collection (a one-to-many or many-to-many association), it will not be deleted, by default. This behaviour is completely consistent - a change to the internal state of another entity should not cause the associated entity to vanish! Likewise, adding an entity to a collection does not cause that entity to become persistent, by default.
Instead, the default behaviour is that adding an entity to a collection merely creates a link between the two entities, while removing it removes the link. This is very appropriate for all sorts of cases. Where it is not appropriate at all is the case of a parent / child relationship, where the life of the child is bound to the lifecycle of the parent.
Suppose we start with a simple <one-to-many> association from Parent to Child.
<set name="children"> <key column="parent_id"/> <one-to-many class="Child"/> </set>
If we were to execute the following code
Parent p = .....; Child c = new Child(); p.getChildren().add(c); session.save(c); session.flush();
Hibernate would issue two SQL statements:
an INSERT to create the record for c
an UPDATE to create the link from p to c
This is not only inefficient, but also violates any NOT NULL constraint on the parent_id column.
The underlying cause is that the link (the foreign key parent_id) from p to c is not considered part of the state of the Child object and is therefore not created in the INSERT. So the solution is to make the link part of the Child mapping.
<many-to-one name="parent" column="parent_id" not-null="true"/>
(We also need to add the parent property to the Child class.)
Now that the Child entity is managing the state of the link, we tell the collection not to update the link. We use the inverse attribute.
<set name="children" inverse="true"> <key column="parent_id"/> <one-to-many class="Child"/> </set>
The following code would be used to add a new Child
Parent p = (Parent) session.load(Parent.class, pid); Child c = new Child(); c.setParent(p); p.getChildren().add(c); session.save(c); session.flush();
And now, only one SQL INSERT would be issued!
To tighten things up a bit, we could create an addChild() method of Parent.
public void addChild(Child c) { c.setParent(this); children.add(c); }
Now, the code to add a Child looks like
Parent p = (Parent) session.load(Parent.class, pid); Child c = new Child(); p.addChild(c); session.save(c); session.flush();
The explicit call to save() is still annoying. We will address this by using cascades.
<set name="children" inverse="true" cascade="all"> <key column="parent_id"/> <one-to-many class="Child"/> </set>
This simplifies the code above to
Parent p = (Parent) session.load(Parent.class, pid); Child c = new Child(); p.addChild(c); session.flush();
Similarly, we don't need to iterate over the children when saving or deleting a Parent. The following removes p and all its children from the database.
Parent p = (Parent) session.load(Parent.class, pid); session.delete(p); session.flush();
However, this code
Parent p = (Parent) session.load(Parent.class, pid); Child c = (Child) p.getChildren().iterator().next(); p.getChildren().remove(c); c.setParent(null); session.flush();
will not remove c from the database; it will ony remove the link to p (and cause a NOT NULL constraint violation, in this case). You need to explicitly delete() the Child.
Parent p = (Parent) session.load(Parent.class, pid); Child c = (Child) p.getChildren().iterator().next(); p.getChildren().remove(c); session.delete(c); session.flush();
Now, in our case, a Child can't really exist without its parent. So if we remove a Child from the collection, we really do want it to be deleted. For this, we must use cascade="all-delete-orphan".
<set name="children" inverse="true" cascade="all-delete-orphan"> <key column="parent_id"/> <one-to-many class="Child"/> </set>
Note: even though the collection mapping specifies inverse="true", cascades are still processed by iterating the collection elements. So if you require that an object be saved, deleted or updated by cascade, you must add it to the collection. It is not enough to simply call setParent().
Suppose we loaded up a Parent in one Session, made some changes in a UI action and wish to persist these changes in a new Session (by calling update()). The Parent will contain a collection of childen and, since cascading update is enabled, Hibernate needs to know which children are newly instantiated and which represent existing rows in the database. Lets assume that both Parent and Child have (synthetic) identifier properties of type java.lang.Long. Hibernate will use the identifier property value to determine which of the children are new. (You may also use the version or timestamp property, see Раздел 9.4.2, «Updating detached objects».)
The unsaved-value attribute is used to specify the identifier value of a newly instantiated instance. unsaved-value defaults to "null", which is perfect for a Long identifier type. If we would have used a primitive identitifier property, we would need to specify
<id name="id" type="long" unsaved-value="0">
for the Child mapping. (There is also an unsaved-value attribute for version and timestamp property mappings.)
The following code will update parent and child and insert newChild.
//parent and child were both loaded in a previous session parent.addChild(child); Child newChild = new Child(); parent.addChild(newChild); session.update(parent); session.flush();
Well, thats all very well for the case of a generated identifier, but what about assigned identifiers and composite identifiers? This is more difficult, since unsaved-value can't distinguish between a newly instantiated object (with an identifier assigned by the user) and an object loaded in a previous session. In these cases, you will probably need to give Hibernate a hint; either
define unsaved-value="null" or unsaved-value="negative" on a <version> or <timestamp> property mapping for the class.
set unsaved-value="none" and explicitly save() newly instantiated children before calling update(parent)
set unsaved-value="any" and explicitly update() previously persistent children before calling update(parent)
none is the default unsaved-value for assigned and composite identifiers.
There is one further possibility. There is a new Interceptor method named isUnsaved() which lets the application implement its own strategy for distinguishing newly instantiated objects. For example, you could define a base class for your persistent classes.
public class Persistent { private boolean _saved = false; public void onSave() { _saved=true; } public void onLoad() { _saved=true; } ...... public boolean isSaved() { return _saved; } }
(The saved property is non-persistent.) Now implement isUnsaved(), along with onLoad() and onSave() as follows.
public Boolean isUnsaved(Object entity) { if (entity instanceof Persistent) { return new Boolean( !( (Persistent) entity ).isSaved() ); } else { return null; } } public boolean onLoad(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) { if (entity instanceof Persistent) ( (Persistent) entity ).onLoad(); return false; } public boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) { if (entity instanceof Persistent) ( (Persistent) entity ).onSave(); return false; }
There is quite a bit to digest here and it might look confusing first time around. However, in practice, it all works out quite nicely. Most Hibernate applications use the parent / child pattern in many places.
We mentioned an alternative in the first paragraph. None of the above issues exist in the case of <composite-element> mappings, which have exactly the semantics of a parent / child relationship. Unfortunately, there are two big limitations to composite element classes: composite elements may not own collections, and they should not be the child of any entity other than the unique parent. (However, they may have a surrogate primary key, using an <idbag> mapping.)
Долгоживущие классы представляют сам weblog и заметки, которые были отосланы в него. Взаимоотношение между данными сущностями будет замэплено как стандартное отношение родитель/ребенок (parent/child), но мы будем использовать упорядоченный bag (ordered bag) вместо множества (set).
package eg; import java.util.List; public class Blog { private Long _id; private String _name; private List _items; public Long getId() { return _id; } public List getItems() { return _items; } public String getName() { return _name; } public void setId(Long long1) { _id = long1; } public void setItems(List list) { _items = list; } public void setName(String string) { _name = string; } }
package eg; import java.text.DateFormat; import java.util.Calendar; public class BlogItem { private Long _id; private Calendar _datetime; private String _text; private String _title; private Blog _blog; public Blog getBlog() { return _blog; } public Calendar getDatetime() { return _datetime; } public Long getId() { return _id; } public String getText() { return _text; } public String getTitle() { return _title; } public void setBlog(Blog blog) { _blog = blog; } public void setDatetime(Calendar calendar) { _datetime = calendar; } public void setId(Long long1) { _id = long1; } public void setText(String string) { _text = string; } public void setTitle(String string) { _title = string; } }
XML-мэппинг, в данном случае, должен быть достаточно простым.
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <hibernate-mapping package="eg"> <class name="Blog" table="BLOGS" lazy="true"> <id name="id" column="BLOG_ID"> <generator class="native"/> </id> <property name="name" column="NAME" not-null="true" unique="true"/> <bag name="items" inverse="true" lazy="true" order-by="DATE_TIME" cascade="all"> <key column="BLOG_ID"/> <one-to-many class="BlogItem"/> </bag> </class> </hibernate-mapping>
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 2.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd"> <hibernate-mapping package="eg"> <class name="BlogItem" table="BLOG_ITEMS" dynamic-update="true"> <id name="id" column="BLOG_ITEM_ID"> <generator class="native"/> </id> <property name="title" column="TITLE" not-null="true"/> <property name="text" column="TEXT" not-null="true"/> <property name="datetime" column="DATE_TIME" not-null="true"/> <many-to-one name="blog" column="BLOG_ID" not-null="true"/> </class> </hibernate-mapping>
Следующий класс демонстрирует некоторые вещи, которые мы может делать с этими классами, используя Hibernate.
package eg; import java.util.ArrayList; import java.util.Calendar; import java.util.Iterator; import java.util.List; import net.sf.hibernate.HibernateException; import net.sf.hibernate.Query; import net.sf.hibernate.Session; import net.sf.hibernate.SessionFactory; import net.sf.hibernate.Transaction; import net.sf.hibernate.cfg.Configuration; import net.sf.hibernate.tool.hbm2ddl.SchemaExport; public class BlogMain { private SessionFactory _sessions; public void configure() throws HibernateException { _sessions = new Configuration() .addClass(Blog.class) .addClass(BlogItem.class) .buildSessionFactory(); } public void exportTables() throws HibernateException { Configuration cfg = new Configuration() .addClass(Blog.class) .addClass(BlogItem.class); new SchemaExport(cfg).create(true, true); } public Blog createBlog(String name) throws HibernateException { Blog blog = new Blog(); blog.setName(name); blog.setItems( new ArrayList() ); Session session = _sessions.openSession(); Transaction tx = null; try { tx = session.beginTransaction(); session.save(blog); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } return blog; } public BlogItem createBlogItem(Blog blog, String title, String text) throws HibernateException { BlogItem item = new BlogItem(); item.setTitle(title); item.setText(text); item.setBlog(blog); item.setDatetime( Calendar.getInstance() ); blog.getItems().add(item); Session session = _sessions.openSession(); Transaction tx = null; try { tx = session.beginTransaction(); session.update(blog); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } return item; } public BlogItem createBlogItem(Long blogid, String title, String text) throws HibernateException { BlogItem item = new BlogItem(); item.setTitle(title); item.setText(text); item.setDatetime( Calendar.getInstance() ); Session session = _sessions.openSession(); Transaction tx = null; try { tx = session.beginTransaction(); Blog blog = (Blog) session.load(Blog.class, blogid); item.setBlog(blog); blog.getItems().add(item); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } return item; } public void updateBlogItem(BlogItem item, String text) throws HibernateException { item.setText(text); Session session = _sessions.openSession(); Transaction tx = null; try { tx = session.beginTransaction(); session.update(item); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } } public void updateBlogItem(Long itemid, String text) throws HibernateException { Session session = _sessions.openSession(); Transaction tx = null; try { tx = session.beginTransaction(); BlogItem item = (BlogItem) session.load(BlogItem.class, itemid); item.setText(text); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } } public List listAllBlogNamesAndItemCounts(int max) throws HibernateException { Session session = _sessions.openSession(); Transaction tx = null; List result = null; try { tx = session.beginTransaction(); Query q = session.createQuery( "select blog.id, blog.name, count(blogItem) " + "from Blog as blog " + "left outer join blog.items as blogItem " + "group by blog.name, blog.id " + "order by max(blogItem.datetime)" ); q.setMaxResults(max); result = q.list(); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } return result; } public Blog getBlogAndAllItems(Long blogid) throws HibernateException { Session session = _sessions.openSession(); Transaction tx = null; Blog blog = null; try { tx = session.beginTransaction(); Query q = session.createQuery( "from Blog as blog " + "left outer join fetch blog.items " + "where blog.id = :blogid" ); q.setParameter("blogid", blogid); blog = (Blog) q.list().get(0); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } return blog; } public List listBlogsAndRecentItems() throws HibernateException { Session session = _sessions.openSession(); Transaction tx = null; List result = null; try { tx = session.beginTransaction(); Query q = session.createQuery( "from Blog as blog " + "inner join blog.items as blogItem " + "where blogItem.datetime > :minDate" ); Calendar cal = Calendar.getInstance(); cal.roll(Calendar.MONTH, false); q.setCalendar("minDate", cal); result = q.list(); tx.commit(); } catch (HibernateException he) { if (tx!=null) tx.rollback(); throw he; } finally { session.close(); } return result; } }
Данная глава демонстрирует несколько мэппингов для более сложных ассоциаций.
Следующая модель взаимоотношений между работодателем, класс Employer и работником Employee использует реальный класс-сущность (entity class) Employment, для представления ассоциации. Это сделано по причине того, что возможно более одного зарегистрированного периода работы одного и того же служащего на одного и того же работодателя. Для представления денежных значений и имен слежащих, используются компоненты (components), MonetoryAmmounts и Name соответсвенно.
Вот возможный мэппинг для данной модели:
<hibernate-mapping> <class name="Employer" table="employers"> <id name="id"> <generator class="sequence"> <param name="sequence">employer_id_seq</param> </generator> </id> <property name="name"/> </class> <class name="Employment" table="employment_periods"> <id name="id"> <generator class="sequence"> <param name="sequence">employment_id_seq</param> </generator> </id> <property name="startDate" column="start_date"/> <property name="endDate" column="end_date"/> <component name="hourlyRate" class="MonetoryAmount"> <property name="amount"> <column name="hourly_rate" sql-type="NUMERIC(12, 2)"/> </property> <property name="currency" length="12"/> </component> <many-to-one name="employer" column="employer_id" not-null="true"/> <many-to-one name="employee" column="employee_id" not-null="true"/> </class> <class name="Employee" table="employees"> <id name="id"> <generator class="sequence"> <param name="sequence">employee_id_seq</param> </generator> </id> <property name="taxfileNumber"/> <component name="name" class="Name"> <property name="firstName"/> <property name="initial"/> <property name="lastName"/> </component> </class> </hibernate-mapping>
А вот схема таблиц, сгенерированная для данного мэппинга, при помощи инструмента SchemaExport:
create table employers ( id BIGINT not null, name VARCHAR(255), primary key (id) ) create table employment_periods ( id BIGINT not null, hourly_rate NUMERIC(12, 2), currency VARCHAR(12), employee_id BIGINT not null, employer_id BIGINT not null, end_date TIMESTAMP, start_date TIMESTAMP, primary key (id) ) create table employees ( id BIGINT not null, firstName VARCHAR(255), initial CHAR(1), lastName VARCHAR(255), taxfileNumber VARCHAR(255), primary key (id) ) alter table employment_periods add constraint employment_periodsFK0 foreign key (employer_id) references employers alter table employment_periods add constraint employment_periodsFK1 foreign key (employee_id) references employees create sequence employee_id_seq create sequence employment_id_seq create sequence employer_id_seq
Рассмотрим следующую модель взаимодействий между работой, класс Work инициатором, класс Author и человеком, Person. Мы изображаем взаимодействие между классами Work и Author, как отношение многие-ко-многим (many-to-many). Для отображения взаимотношений между сущностями Author и Person, мы используем ассоциацию один-к-одному (one-to-one). Другой вариант, это использование наследования следующим образом: класс Author расширяет (extend) Person.
Следующий мэппинг, правильно отображет данные отношения между классами:
<hibernate-mapping> <class name="Work" table="works" discriminator-value="W"> <id name="id" column="id"> <generator class="native"/> </id> <discriminator column="type" type="character"/> <property name="title"/> <set name="authors" table="author_work" lazy="true"> <key> <column name="work_id" not-null="true"/> </key> <many-to-many class="Author"> <column name="author_id" not-null="true"/> </many-to-many> </set> <subclass name="Book" discriminator-value="B"> <property name="text"/> </subclass> <subclass name="Song" discriminator-value="S"> <property name="tempo"/> <property name="genre"/> </subclass> </class> <class name="Author" table="authors"> <id name="id" column="id"> <!-- The Author must have the same identifier as the Person --> <generator class="assigned"/> </id> <property name="alias"/> <one-to-one name="person" constrained="true"/> <set name="works" table="author_work" inverse="true" lazy="true"> <key column="author_id"/> <many-to-many class="Work" column="work_id"/> </set> </class> <class name="Person" table="persons"> <id name="id" column="id"> <generator class="native"/> </id> <property name="name"/> </class> </hibernate-mapping>
В данном мэппинге используется четыре таблицы. Таблицы works, authors и persons содержат информацию о работе, инициаторе и человеке соответсвенно. Таблица author_work, является таблицей-ассоциаций (association table), связывающей инициаторов с работами. Вот схема таблиц, сгенерированная при помощи SchemaExport:
create table works ( id BIGINT not null generated by default as identity, tempo FLOAT, genre VARCHAR(255), text INTEGER, title VARCHAR(255), type CHAR(1) not null, primary key (id) ) create table author_work ( author_id BIGINT not null, work_id BIGINT not null, primary key (work_id, author_id) ) create table authors ( id BIGINT not null generated by default as identity, alias VARCHAR(255), primary key (id) ) create table persons ( id BIGINT not null generated by default as identity, name VARCHAR(255), primary key (id) ) alter table authors add constraint authorsFK0 foreign key (id) references persons alter table author_work add constraint author_workFK0 foreign key (author_id) references authors alter table author_work add constraint author_workFK1 foreign key (work_id) references works
Теперь рассмотрим модель взаимоотношений между клиентом, класс Customer; заказом Order; и классами пункт заказа LineItem, и товар Product. Отоношение между классами Customer и Order явлется отношением один-ко-многим (one-to-many); но как мы должны отобразить отношение Order / LineItem / Product? Мы выбрали вариант мэппига с использованием LineItem, как класса-ассоциации (association class), для представления ассоциации многие-ко-многим (many-to-many) между сущностями Order и Product. В Hibernate такой мэппинг называется мэппингом с использованием составного элемента (composite element), в данном случае LineItem -- класс составного элемента.
Мэппинг:
<hibernate-mapping> <class name="Customer" table="customers"> <id name="id"> <generator class="native"/> </id> <property name="name"/> <set name="orders" inverse="true" lazy="true"> <key column="customer_id"/> <one-to-many class="Order"/> </set> </class> <class name="Order" table="orders"> <id name="id"> <generator class="native"/> </id> <property name="date"/> <many-to-one name="customer" column="customer_id"/> <list name="lineItems" table="line_items" lazy="true"> <key column="order_id"/> <index column="line_number"/> <composite-element class="LineItem"> <property name="quantity"/> <many-to-one name="product" column="product_id"/> </composite-element> </list> </class> <class name="Product" table="products"> <id name="id"> <generator class="native"/> </id> <property name="serialNumber"/> </class> </hibernate-mapping>
Таблицы customers, orders, line_items и products, содержат информацию о клиенте, заказе, элементах заказа и товаре соответсвенно. Таблица line_items, также выполняет функции связывающей таблицы для заказов и товаров.
create table customers ( id BIGINT not null generated by default as identity, name VARCHAR(255), primary key (id) ) create table orders ( id BIGINT not null generated by default as identity, customer_id BIGINT, date TIMESTAMP, primary key (id) ) create table line_items ( line_number INTEGER not null, order_id BIGINT not null, product_id BIGINT, quantity INTEGER, primary key (order_id, line_number) ) create table products ( id BIGINT not null generated by default as identity, serialNumber VARCHAR(255), primary key (id) ) alter table orders add constraint ordersFK0 foreign key (customer_id) references customers alter table line_items add constraint line_itemsFK0 foreign key (product_id) references products alter table line_items add constraint line_itemsFK1 foreign key (order_id) references orders
Используйте класс Адрес для инкапсулирования следующей информации улица, пригород, штат, почтовый код. Данный подход приводит к повторному использованию кода и упрощает рефакторинг.
В Hibernate свойства-идентификаторы являются опциональными, но имеется много причин, по которым вы должны их использовать. Мы рекомендуем, чтобы идентификаторы были 'синтетическими' (synthetic), т.е. не несущими никакой смысловой нагрузки для бизнеса; также рекомендуем, чтобы идентификторы были непримитивных типов. Для макскомальной гибокости, используйте java.lang.Long или java.lang.String.
Не используйте единственный монолитный документ-мэппинга. Отображайте класс com.eg.Foo в файле com/eg/Foo.hbm.xml. Это имеет особый смысл при работе в команде.
Размещайте мэппиги вместе с классами, для которых они созданы.
Это хорошая практика, если ваши запросы используют SQL-функции несоответствующие ANSI стандарту. Размещение строк запросов в мэппинг-файлах, делает приложение более портируемым.
Как и в JDBC, всегда заменяйте неконстантые значения знаком "?". Никогда не используйте манипуляций со строками, для вставки неконстантых значений в запрос! Или еще лучше, рассмотрите вариант использования именных параметров (named parameters) в запросах.
Hibernate позволяет приложениям управлять JDBC-соединенями, но данный подход должен использоваться только в самых крайних случаях. Если вы не можете использовать встроенные провайдеры соединений (connections providers), обдумайте вариант с использованием вашей собственной реализации net.sf.hibernate.connection.ConnectionProvider.
Предположим у вас имеется Java-тип, скажем из какой-либо библиотеки, который вам необходимо сделать долгоживущим, но этот тип не предоставляет методов доступа (accessors) необходимых для того чтобы замэпить его как компонент (component). Вы должны рассмотреть вариант с реализацией net.sf.hibernate.UserType. Данный подход освобождает код пиложения от необходимости преобразований Java-типа в Hibernate-тип и наоборот.
В критических по производительности местах вашей системы, при выполнении некоторых видов операций (например массовые изменения/удаления), ваша система может получить выигрыш в производительности от использования JDBC-вызовов напрямую. Но пожалуйста удостоверьтесь что это на самом деле "узкое место" вашей системы. И не стоит считать что непосредственное использование JDBC-вызовов обязательно быстрее. Если вам необходимо использовать JDBC-вызовы напрямую, то наиболее правильное решение, это открыть новую Hibernate-сессию и использовать её JDBC-соединение. Таким образом вы можете использовать единую стратегию транзакций и нижележащий провайдер соединений.
Время от времени сессия выполняет синхронизацию своего состояния (состояния долгоживущих объектов находящихся в сессии) с базой данных. Если данная операция выполняется очень часто, это скажется на производительности. Иногда вы можете минимизировать ненужные вызовы Session.flush() путем отключения автоматического вызова данного метода или даже изменив порядок выполнения запросов и других операций внутри определенной транзакции.
При использовании servlet / session bean архитектуры, вы можете передавать долгоживущие объекты, загруженные в session bean'е, в servlet / JSP слой. Используйте новую Hibernate-сессию для обработки каждого запроса. Используйте вызов Session.update() или Session.saveOrUpdate() для обновления состояния долгоживущего объекта.
Для достижения наилучшего масштабирования приложения, Транзакции Уровня Баз Данных (Database Transactions) должны быть по возможности наиболее короткими. Тем не менее, часто необходимо реализовать долговыполняющиеся Транзакции Уровня Приложения (long running Application Transactions), которые со стороны пользователя выглядят как единая единица-работы (single unit-of-work). Данные Транзакции Уровня Приложения (Application Transaction) должны быть выполнены в нескольких циклах запрос-ответ. Используйте либо Отсоединенные Объекты (Detached Objects), либо, в двухзвенных приложениях, просто отсоедините (Session.disconnect()) Hibernate-сессию от используемого JDBC-соединения и переподсоединяйте сессию (Session.reconnect()) для каждого последующего запроса. Никогда не используйте единую Hibernate-сессию для более чем одной Транзакции Уровня Приложения (Application Transaction usecase); Иначе вы можете столкнуться с использованием устаревших данных (stale data), т.к. Hibernate-сессия является кэшем первого уровня.
Это скорее необходимая, чем "лучшая" практика использования. Когда случается исключительная ситуация, откатите текщую транзакцию (Transaction.rollback()) и закройте Hibernate-сессию (Session.close()). Если вы этого не сделаете, Hibernate не может гарантировать что данное состояние объектов в памяти (в сессии) точно отображает состояние объектов в базе данных. Как один из особых случаев, не используйте Session.load() для определения существует ли в базе данных объект с заданным идентификатором; взамен, используйте вызов find() или get(). Некоторые исключения, являются восстанавливаемыми (recoverable), например, StaleObjectStateException и ObjectNotFoundException.
Обдуманно используйте стратегию полной выборки (eager, outer-join) данных. Используйте прокси (proxy) классы и/или "ленивые" коллекции для большинства ассоциаций с классами, которые не кэшируютя на уровне JVM (JVM-level cache). Для ассоциаций с кэшируемыми классами, для которых имеется большая вероятность удачного обращения в кэш (cache hit), явно отключайте стратегию полной выборки (eager fetching), используя outer-join="false". В случае когда выборка с использованием outer-join уместна, используйте HQL запрос с ключевым словом left join fetch.
Спрячьте за интерфейсом весь (Hibernate) код, в котором происходит обращение к данным (data-access code). Используйте совместно следующие шаблоны DAO и Thread Local Session. Вы также можете написать JDBC-код для чтения, сохранения ваших долгоживущих классов, ассоциированных с Hibernate посредством UserType. (Данный совет предназначен для "достаточно больших" приложений; он не подходит для приложений с пятью таблицами!)
Если вам необходимо сравнивать объекты за пределами сессии, вы должны реализовать методы equals() и hashCode() для ваших объектов (shl: я так понимаю что авторы имели ввиду что два объекта загруженные в одной сессии можно сравнивать через identity, т.е. с использованием оператора '=='). Внутри одной сессии, индивидуальность (idenity) Java-объектов гарантирована. Если вы реализуете эти методы, не вздумайте использовать идентификаторы базы данных (поля которые отображаются в колонки, являющиеся идентификаторами БД). Временный объект, объект еще не сохраненный в БД, не имеет присвоенного ему идентификатора БД, Hibernate присвоит его, когда объект будет сохранен в БД. Но если объект находится в java.util.Set'е в моммент сохранения, то его хэш-код (hash code) изменится, нарушая соглашение (contract) для hashCode(). Для реализации equals() и hashCode(), используйте уникальный бизнес-ключ, т.е. сравнивайте уникальные комбинации свойств класса. Запомните, что данный ключ должен быть неизменным и уникальным только до тех пор пока объект находится в java.util.Set'е, не на протяжении всего жизненного цикла объекта (т.е. бизнес-ключ не обязан быть постоянным как первичный ключ БД). Никогда не используйте коллекций при реализации equals(), из-за ленивой инициализации (lazy loading) и будьте осторожны с другими ассоциированными классами, которые могут иметь настроенные для них прокси (proxy).
Хорошие примеры использования настоящих ассоциаций many-to-many, очень редки. Как правило, вам необходимо сохранять дополнительную информацию в "связывающей таблице" (link table). В этом случае, намного лучше использовать ассоциацию one-to-many на промежуточный "связывающий класс" (link class). На самом деле, мы думаем что большинство всех ассоциаций, являются ассоциациями one-to-many и many-to-one. Вы должны быть внимательны при использовании других видов ассоциаций, каждый раз перед использованием экзотической ассоциации, стоит спросить себя, так ли она вам необходима.