ОглавлениеCore
 Скачать 1.53 Mb.
|
|
Query – интерфейс позволяет выполнять запросы к БД. Запросы написаны на HQL или на SQL. Что такое EntityManager? Какие функции он выполняет? EntityManager – интерфейс JPA, который описывает API для всех основных операций над Entity, а также для получения данных и других сущностей JPA. Основные операции: 1. Операции над Entity: persist (добавление Entity), merge (обновление), remove (удаление), refresh (обновление данных), detach (удаление из управление JPA), lock (блокирование Entity от изменений в других thread). 2. Получение данных: find (поиск и получение Entity), createQuery, createNamedQuery, createNativeQuery, contains, createNamedStoredProcedureQuery, createStoredProcedureQuery. 3. Получение других сущностей JPA: getTransaction, getEntityManagerFactory, getCriteriaBuilder, getMetamodel, getDelegate. 4. Работа с EntityGraph: createEntityGraph, getEntityGraph. 5. Общие операции над EntityManager или всеми Entities: close, clear, isOpen, getProperties, setProperty. Объекты EntityManager не являются потокобезопасными. Это означает, что каждый поток должен получить свой экземпляр EntityManager, поработать с ним и закрыть его в конце. Каким условиям должен удовлетворять класс, чтобы являться Entity? Entity – это легковесный хранимый объект бизнес логики. Основная программная сущность – это entity-класс, который может использовать дополнительные классы, которые могут использоваться как вспомогательные классы или для сохранения состояния еntity. Требования к e ntity-классу : • должен быть помечен аннотацией Entity или описан в XML-файле; • должен содержать public или protected конструктор без аргументов (он также может иметь конструкторы с аргументами) – при получении данных из БД и формировании из них объекта сущности Hibernate должен создать этот объект сущности$ • должен быть классом верхнего уровня (top-level class); • не может быть enum или интерфейсом; • не может быть финальным классом (final class); • не может содержать финальные поля или методы, если они участвуют в маппинге (persistent final methods or persistent final instance variables); • если объект entity-класса будет передаваться по значению как отдельный объект (detached object), например, через удаленный интерфейс (through a remote interface), он должен реализовывать интерфейс Serializable; • поля entity-класса должны быть напрямую доступны только методам самого entity- класса и не должны быть напрямую доступны другим классам, использующим этот entity. Такие классы должны обращаться только к методам (getter/setter методам или другим методам бизнес-логики в entity-классе); • должен содержать первичный ключ, то есть атрибут или группу атрибутов, которые уникально определяют запись этого entity-класса в базе данных. Может ли абстрактный класс быть Entity? Может, при этом он сохраняет все свойства Entity, за исключением того, что его нельзя непосредственно инициализировать. Может ли entity-класс наследоваться от не entity-классов (non-entity classes)? Может. Может ли entity-класс наследоваться от других entity-классов? Может. Может ли НЕ entity-класс наследоваться от entity-класса? Может. Что такое встраиваемый (embeddable) класс? Какие требования JPA устанавливает к встраиваемым (embeddable) классам? Embeddable-класс – это класс, который не используется сам по себе, а является частью одного или нескольких entity-классов. Entity-класс может содержать как одиночные встраиваемые классы, так и коллекции таких классов. Также такие классы могут быть использованы как ключи или значения map. Во время выполнения каждый встраиваемый класс принадлежит только одному объекту entity-класса и не может быть использован для передачи данных между объектами entity-классов (то есть такой класс не является общей структурой данных для разных объектов). В целом, такой класс служит для того, чтобы выносить определение общих атрибутов для нескольких entity. Такие классы должны удовлетворять тем же правилам, что entity-классы, за исключением того, что они не обязаны содержать первичный ключ и быть отмечены аннотацией Entity. Embeddable-класс должен быть помечен аннотацией @Embeddable или описан в XML- файле конфигурации JPA. А поле этого класса в Entity аннотацией @Embedded. Embeddable-класс может содержать другой встраиваемый класс. Встраиваемый класс может содержать связи с другими Entity или коллекциями Entity, если такой класс не используется как первичный ключ или ключ map'ы. Что такое Mapped Superclass? Mapped Superclass – это класс, от которого наследуются Entity, он может содержать анотации JPA, однако сам такой класс не является Entity, ему не обязательно выполнять все требования, установленные для Entity (например, он может не содержать первичного ключа). Такой класс не может использоваться в операциях EntityManager или Query. Такой класс должен быть отмечен аннотацией MappedSuperclass или описан в xm- файле. Создание такого класса-предка оправдано тем, что заранее определяется ряд свойств и методов в сущностях. Использование такого подхода позволило сократить количество кода. Какие три типа стратегий наследования мапинга (Inheritance Mapping Strategies) описаны в JPA? Inheritance Mapping Strategies описывает как JPA будет работать с классами-наследниками Entity: 1. Одна таблица на всю иерархию классов (SINGLE_TABLE) – все entity со всеми наследниками записываются в одну таблицу, для идентификации типа entity определяется специальная колонка «discriminator column». Например, есть entity Animals c классами- потомками Cats и Dogs. При такой стратегии все entity записываются в таблицу Animals, но при этом имеют дополнительную колонку animalType, в которую соответственно пишется значение «cat» или «dog». Минусом является то, что в общей таблице будут созданы все поля, уникальные для каждого из классов-потомков, которые будут пусты для всех других классов-потомков. Например, в таблице animals окажется и скорость лазанья по дереву от cats, и может ли пес приносить тапки от dogs, которые будут всегда иметь null для dog и cat соответственно. Нельзя делать constraints notNull, но можно использовать триггеры. 2. Стратегия «соединения» (JOINED_TABLE) – в этой стратегии каждый класс entity сохраняет данные в свою таблицу, но только уникальные поля (не унаследованные от классов-предков) и первичный ключ, а все унаследованные колонки записываются в таблицы класса-предка, дополнительно устанавливается связь (relationships) между этими таблицами, например, в случае классов Animals будут три таблицы: animals, cats, dogs. Причем в cats будет записан только ключ и скорость лазанья, в dogs – ключ и умеет ли пес приносить палку, а в animals все остальные данные cats и dogs c ссылкой на соответствующие таблицы. Минусом является потеря производительности от объединения таблиц (join) для любых операций. 3. Таблица для каждого класса (TABLE_PER_CLASS) – каждый отдельный класс- наследник имеет свою таблицу, т. е. для cats и dogs все данные будут записываться просто в таблицы cats и dogs как если бы они вообще не имели общего суперкласса. Минусом является плохая поддержка полиморфизма (polymorphic relationships) и то, что для выборки всех классов иерархии потребуются большое количество отдельных sql-запросов или использование UNION-запроса. Для задания стратегии наследования используется аннотация Inheritance (или соответствующие блоки). Как мапятся Enum'ы? @Enumerated(EnumType.STRING) означает, что в базе будут храниться имена Enum. @Enumerated(EnumType.ORDINAL) – в базе будут храниться порядковые номера Enum. Другой вариант – можно смапить enum в БД и обратно в методах с аннотациями @PostLoad и @PrePersist. @EntityListener над классом Entity, где указать класс, в котором создать два метода, помеченных этими аннотациями. Идея в том, чтобы в сущности иметь не только поле с Enum, но и вспомогательное поле. Поле с Enum аннотируем @Transient, а в БД будет храниться значение из вспомогательного поля. В JPA с версии 2.1 можно использовать Converter для конвертации Enum’а в некое его значение для сохранения в БД и получения из БД. Нужно лишь создать новый класс, который реализует javax.persistence.AttributeConverter и аннотировать его с помощью @Converter и поле в сущности аннотацией @Convert. Как мапятся даты (до Java 8 и после)? Аннотация @Temporal до Java 8, в которой надо было указать, какой тип даты хотим использовать. В Java 8 и далее аннотацию ставить не нужно. Как «смапить» коллекцию примитивов? @ElementCollection @OrderBy Если у сущности есть поле с коллекцией, то обычно ставят над ним аннотации @OneToMany либо @ManyToMany. Но данные аннотации применяются, когда это коллекция других сущностей (entities). Если у сущности коллекция не других сущностей, а базовых или встраиваемых (embeddable) типов, то для этих случаев в JPA имеется специальная аннотация @ElementCollection, которая указывается в классе сущности над полем коллекции. Все записи коллекции хранятся в отдельной таблице, то есть в итоге получаем две таблицы: одну для сущности, вторую для коллекции элементов. При добавлении новой строки в коллекцию она полностью очищается и заполняется заново, так как у элементов нет id. Можно решить с помощью @OrderColumn. @CollectionTable позволяет редактировать таблицу с коллекцией. Какие есть виды связей? Существуют 4 типа связей: 1. OneToOne – когда один экземпляр Entity может быть связан не больше чем с одним экземпляром другого Entity. Необходимо ставить forieghnKey на родительскую таблицу и аннотацию JoinColomun, в атрибуте name объяснить, к какой колонке ссылаться на родительской сущности. Что стоит в поле, где все связано? Стоит тип другой сущности. 2. OneToMany – когда один экземпляр Entity может быть связан с несколькими экземплярами других Entity. Когда одна сущность может ссылаться ко многим сущностям. Храним коллекцию. 3. ManyToOne – обратная связь для OneToMany. Несколько экземпляров Entity могут быть связаны с одним экземпляром другого Entity. Несколько машин может быть у нескольких юзеров. Одна сущность хранится. 4. ManyToMany – экземпляры Entity могут быть связаны с несколькими экземплярами друг друга. Каждый из двух Entity может быть по несколько других Entity. Много сущностей могут относиться к многим сущностями. Сводная таблица с айдишниками, коллекции коллекций хранятся. Каждую из которых можно разделить ещё на два вида: 1. Bidirectional с использованием @MappedBy на стороне, где указывается @OneToMany 2. Unidirectional. Bidirectional – ссылка на связь устанавливается у всех Entity, то есть в случае OneToOne A-B в Entity A есть ссылка на Entity B, в Entity B есть ссылка на Entity A. Entity A считается владельцем этой связи (это важно для случаев каскадного удаления данных, тогда при удалении A также будет удалено B, но не наоборот). Undirectional – ссылка на связь устанавливается только с одной стороны, то есть в случае OneToOne A-B только у Entity A будет ссылка на Entity B, у Entity B ссылки на A не будет. Что такое владелец связи? В отношениях между двумя сущностями всегда есть одна владеющая сторона, а зависимой может и не быть, если это однонаправленные отношения. По сути, у кого есть внешний ключ на другую сущность, тот и владелец связи. То есть, если в таблице одной сущности есть колонка, содержащая внешние ключи от другой сущности, то первая сущность признается владельцем связи, вторая сущность – зависимой. В однонаправленных отношениях сторона, которая имеет поле с типом другой сущности, является владельцем этой связи по умолчанию. Что такое каскады? Каскадирование – это какое-то действие с целевой Entity, то же самое действие будет применено к связанной Entity. JPA CascadeType: • ALL гарантирует, что все персистентные события, которые происходят на родительском объекте, будут переданы дочернему объекту; • PERSIST означает, что операции save() или persist() каскадно передаются связанным объектам; • MERGE означает, что связанные entity объединяются, когда объединяется entity- владелец; • REMOVE удаляет все entity, связанные с удаляемой entity; • DETACH отключает все связанные entity, если происходит «ручное отключение»; • REFRESH повторно считывает значение данного экземпляра и связанных сущностей из базы данных при вызове refresh(). Разница между PERSIST и MERGE? persist(entity) следует использовать с новыми объектами, чтобы добавить их в БД (если объект уже существует в БД, будет выброшено исключение EntityExistsException). Если использовать merge(entity), то сущность, которая уже управляется в контексте персистентности, будет заменена новой сущностью (обновленной), и копия этой обновленной сущности вернется обратно. Рекомендуется использовать для уже сохраненных сущностей. Какие два типа fetch-стратегии в JPA вы знаете? 1. LAZY – Hibernate может загружать данные не сразу, а при первом обращении к ним, но так как это необязательное требование, то Hibernate имеет право изменить это поведение и загружать их сразу. Это поведение по умолчанию для полей, аннотированных @OneToMany, @ManyToMany и @ElementCollection. В объект загружается прокси lazy-поля. Если там стоит коллекция, то это будет коллекция Hibernate, именуемая типом коллекции bag(). Подгрузка должна происходить в одной транзакции или пока не закроем ЕнтитуМенеджер. Если обратимся за персистетнымКонтекстом, то LazyEnitialization. Если используем Бэк, то он использует Лист и Сет и т. д. 2. EAGER – данные поля будут загружены немедленно. Это поведение по умолчанию для полей, аннотированных @Basic, @ManyToOne и @OneToOne. Все, что заканчивается на One – Eager, Many – Lazy. Для кого можем использовать ManyToOne? Для владельца связи. Какие четыре статуса жизненного цикла Entity-объекта (Entity Instance’s Life Cycle) вы можете перечислить? • transient (new) – свежесозданная оператором new() сущность не имеет связи с базой данных, не имеет данных в базе данных и не имеет сгенерированных первичных ключей и не имеет контекста Персистентности. При сохранении переходит в managed. • managed – объект уже создан и получает первичный ключ, управляется контекстом персистентности.( сохранен в БД, имеет primary key), переходит под управляется JPA, если вызываем detached, то полностью отвязываем от контекста. • detached – не управляется JPA, но может существовать в БД, объект создан, но не управляется JPA. В этом состоянии сущность не связана со своим контекстом (отделена от него) и нет экземпляра Session, который бы ей управлял. • removed – объект создан, управляется JPA, будет удален из БД, при commit-е транзакции статус станет опять detached. Как влияет операция persist на Entity-объекты каждого из четырех статусов? • new → managed, объект будет сохранен в базу при commit-е транзакции или в результате flush-операций; • managed → операция игнорируется, однако зависимые Entity могут поменять статус на managed, если у них есть аннотации каскадных изменений; • detached → exception сразу или на этапе commit-а транзакции; • removed → managed, но только в рамках одной транзакции. Как влияет операция remove на Entity-объекты каждого из четырех статусов? • new → операция игнорируется, однако зависимые Entity могут поменять статус на removed, если у них есть аннотации каскадных изменений и они имели статус managed; • managed → removed, запись объекта в базе данных будет удалена при commit-е транзакции (также произойдут операции remove для всех каскаднозависимых объектов); • detached → exception сразу или на этапе commit-а транзакции; • removed → операция игнорируется. Как влияет операция merge на Entity-объекты каждого из четырех статусов? • new → будет создан новый managed entity, в который будут скопированы данные прошлого объекта; • managed → операция игнорируется, однако операция merge сработает на каскаднозависимые Entity, если их статус не managed; • detached → либо данные будут скопированы в существующий managed entity с тем же первичным ключом, либо создан новый managed, в который скопируются данные; • removed → exception сразу или на этапе commit-а транзакции. Как влияет операция refresh на Entity-объекты каждого из четырех статусов? • managed → будут восстановлены все изменения из базы данных данного Entity, также произойдет refresh всех каскаднозависимых объектов; • new, removed, detached → exception. Как влияет операция detach на Entity-объекты каждого из четырех статусов? • managed, removed → detached; • new, detached → операция игнорируется. Для чего нужна аннотация Basic? @Basic указывает на простейший тип маппинга данных на колонку таблицы базы данных. В параметрах аннотации можно указать fetch стратегию доступа к полю и является ли это поле обязательным или нет. Может быть применена к полю любого из следующих типов: • примитивы и их обертки; • java.lang.String; • java.math.BigInteger; • java.math.BigDecimal; • java.util.Date; • java.util.Calendar; • java.sql.Date; • java.sql.Time; • java.sql.Timestamp; • byte[] or Byte[]; • char[] or Character[]; • enums; • любые другие типы, которые реализуют Serializable. Аннотацию @Basic можно не ставить, как это и происходит по умолчанию. Аннотация @Basic определяет 2 атрибута: 1. |