Java Programmer Crib 1: JPA and Hibernate in Questions and Answers

General issues

• Question 1. What is JPA?
  
  Answer

  JPA (Java Persistence API) is a Java EE and Java SE specification that describes a management system for saving java objects to relational database tables in a convenient form. Java itself does not contain JPA implementations, however there are many implementations of this specification from different companies (open and not). This is not the only way to save java objects in databases (ORM systems), but one of the most popular in the Java world.
  
  

  Original

  JPA (Java Persistence API) is a specification of the Java EE and Java SE. This is a technical application for a Java application developer.
  

  
  
  
  
• Question 2. How does JPA differ from Hibernate?
  
  Answer

  Hibernate is one of the most popular open source implementations of the latest specification (JPA 2.1). Even the most popular, almost standard de facto. That is, JPA only describes rules and APIs, and Hibernate implements these descriptions, however Hibernate (like many other JPA implementations) has additional features not described in JPA (and not portable to other JPA implementations).
  
  
  
• Question 3. Can I use JPA with noSQl databases?
  
  Answer

  In general, the JPA specification speaks only of mapping java objects into relational database tables, but there are a number of implementations of this standard for noSql databases: Kundera , DataNucleus , ObjectDB, and a number of others. Naturally, with this, not all specification-specific features for relational databases are transferred to the nosql database in full.
  
  
  
• Question 4. How does JPA differ from JDO?
  
  Answer

  JPA (Java Persistence API) and Java Data Objects (JDO) are two specifications for storing java objects in databases. If JPA is concentrated only on relational databases, then JDO is a more general specification that describes the ORM for any possible bases and repositories. In principle, JPA can be regarded as a part of the JDO specification specialized on relativistic bases, even though the API of these two specifications does not completely coincide. The “developers" of the specifications are also different - if JPA is developed as JSR , then JDO was first developed as JSR , now it is developed as an Apache JDO project. More details about the comparison of functionality and API specifications can be found here .
  
  
  
• Question 5. What is Entity?
  
  Answer

  Entity is a lightweight persistent domain object. The main program entity is the entity class, which can also use additional classes, which can be used as auxiliary classes or to maintain state of entity.
  
  Java Persistence 2.1. Chapter 2
  
  

  Original

  An entity is a lightweight persistent domain object.
  The primary programming artifact is the entity class. Can be used
  what is the state of the entity.
  

  
  
  
  
• Question 6. Can the Entity class inherit from non-Entity classes?
  
  Answer

  Can
  
  Java Persistence 2.1. Chapter 2.1
  
  

  Original

  Entities may extend non-entity classes ...
  

  
  
  
  
• Question 7. Can an Entity class inherit from other Entity classes?
  
  Answer

  Can also
  
  Java Persistence 2.1. Chapter 2.1
  
  

  Original

  Entities may extend non-entity classes
  

  
  
  
  
• Question 8. Can a non-Entity class inherit from an Entity class?
  
  Answer

  And this is also permissible
  
  Java Persistence 2.1. Chapter 2.1
  
  

  Original

  Entity may extend entity.
  

  
  
  
  
• Question 9. Can Entity be an abstract class?
  
  Answer

  Perhaps, at the same time, it retains all the properties of the Entity, except that it cannot be directly initialized.
  
  Java Persistence 2.1. Chapter 2.11.1
  
  

  Original

  An abstract class can be specified as an entity. An abstract entity differs from a concrete entity only in
  that it cannot be directly instantiated. An abstract entity
  queries (which will operate over and / or retrieve instances of its concrete subclasses).
  

  
  
  
  
• Question 10. What are the JPA requirements for the Entity classes you can list (at least six requirements)?
  
  Answer

  1) The Entity class must be annotated with the Entity or described in the XML configuration file JPA,
  2) The Entity class must contain a public or protected constructor with no arguments (it can also have constructors with arguments),
  3) Entity class must be a top-level class (top-level class),
  4) Entity class cannot be enum or interface,
  5) The Entity class cannot be a final class (final class),
  6) The Entity class cannot contain final fields or methods if they are involved in mapping (persistent final methods or persistent final instance variables),
  7) If an object of the Entity class is passed by value as a separate object (detached object), for example, through a remote interface (through a remote interface), it must also implement a Serializable interface,
  8) Fields of the Entity class should be directly accessible only to the methods of the Entity class itself and should not be directly accessible to other classes using this Entity. Such classes should refer only to methods (getter / setter methods or other business logic methods in the Entity class),
  9) The Enity class must contain a primary key, that is, an attribute or group of attributes that uniquely define a record of this Enity class in the database,
  
  Java Persistence 2.1. Chapter 2.1 and 2.4
  
  

  Original

  1. The entity class must be annotated with the XML descriptor as an
  entity.
  2. The entity class must have a no-arg constructor. The entity class may have other constructors as well.
  3. The no-arg constructor must be public or protected.
  4. The entity class must be a top-level class. An enum or interface must be defined as an entity.
  5. The entity class must not be final. Class may be
  final.
  6. If an entity is a detached object (eg, through a remote interface), the
  entity class must implement the Serializable interface.
  7. Entities support inheritance, polymorphic associations, and polymorphic queries.
  8. Both abstract and concrete classes can be entities. Entities may extend non-entity classes as well
  extend entity classes.
  10. It can be consistent with the junction variables, which may correspond to JavaBeans.
  properties. An instance variable must be directly accessed only from within the methods of
  entity by the entity instance itself. Instance variables must be accessed by clients of the entity. The
  it is the accessor methods (getter / setter
  methods) or other business methods.
  ...
  2.4 Primary Keys and Entity Identity
  Every entity must have a primary key.
  

  
  
  
  
• Question 11. What are the two types of elements the Entity classes have? Or in other words, list two types of access (access) to the elements of the Entity classes.
  
  Answer

  JPA indicates that it can work both with properties of classes (property), designed in the style of JavaBeans, or with fields (field), that is, class variables (instance variables). Accordingly, the type of access will be either property access or field access.
  
  Java Persistence 2.1. Chapter 2.2
  
  

  Original

  It is accessed by the persistence provider [1] either through JavaBeans
  style property accessors (“property access”) or via instance variables (“field access”). Whether persistent
  properties or persistent fields
  given type or entity hierarchy is determined as described in Section 2.3, “Access Type”.
  

  
  
  
  
• Question 12. What is the attribute of the Entity class in JPA terminology?
  
  Answer

  JPA indicates that it can work both with properties of classes (property), designed in the style of JavaBeans, or with fields (field), that is, class variables (instance variables). Both types of elements of an Entity class are called attributes of the Entity class.
  
  Java Persistence 2.1. Chapter 2.2
  
  

  Original

  It is accessed by the persistence provider [1] either through JavaBeans
  style property accessors (“property access”) or via instance variables (“field access”). Whether persistent
  properties or persistent fields
  given type or entity hierarchy is determined as described in Section 2.3, “Access Type”.
  Terminology Note: The fields are generically
  “attributes” of the class.
  

  
  
  
  
• Question 13. What types of data are allowed in the attributes of the Entity class (fields or properties)?
  
  Answer

  Valid attribute types for Entity classes:
  1. primitive types and their Java wrappers,
  2. lines
  3. any Java serializable types (implementing the Serializable interface),
  4. enums;
  5. entity types;
  6. embeddable classes
  7. and type 1-6 collections
  
  Java Persistence 2.1. Chapter 2.2
  
  

  Original

  The following types are: java.lang.String; other Java serializable types (including wrappers of the primitive types, java.math.BigInteger, java.math.BigDecimal, java.util.Date, java.util.Calendar [5], java.sql.Date, java.sql.Time , java.sql.Timestamp, byte [], Byte [], char [], Character [], and user-defined types that implement the Serializable
  interface); enums; entity types; collections of entity types; embeddable classes (see Section 2.5); collections of basic and embeddable types (see Section 2.6).
  

  
  
  
  
• Question 14. What data types can be used in the attributes included in the primary key of the Entity class (composite or simple) so that the resulting primary key can be used for any database? And in the case of auto-generated primary key (generated primary keys)?
  
  Answer

  Valid attribute types included in the primary key are:
  1. primitive types and their Java wrappers,
  2. lines
  3. BigDecimal and BigInteger,
  4. java.util.Date and java.sql.Date,
  
  In the case of auto-generated primary key (generated primary keys) valid
  1. only numeric types
  
  If other types of data are used in the primary key, it can work only for some databases, i.e. becomes not portable (not portable),
  
  Java Persistence 2.1. Chapter 2.4
  
  

  Original

  The following are the types: any Java primitive type; any primitive wrapper type; java.lang.String; java.util.Date; java.sql.Date; java.math.BigDecimal; java.math.BigInteger ... Entities whose primary keys use types. If generated keys are used, only integral types will be portable.
  

  
  
  
  

Complex structures JPA

• Question 15. What is the Embeddable class?
  
  Answer

  The Embeddable class is a class that is not used by itself, only as part of one or more Entity classes. An entity class can contain both single embedded classes and collections of such classes. Also such classes can be used as keys or map values. At run time, each embeddable class belongs to only one object of the Entity class and cannot be used to transfer data between the objects of the Entity classes (that is, such a class is not a common data structure for different objects). In general, such a class serves to make the definition of common attributes for several Entity, we can assume that JPA simply embeds in the Entity instead of an object of such a class, the attributes it contains.
  
  Java Persistence 2.1. Chapter 2.5
  
  

  Original

  An entity may use an entity state. Instances of these classes, unlike
  entity instances do not have persistent identity of their own. Instead, they exist only as part of the state
  of the entity to which they belong. An entity may have collections of embeddables as well as single-valued
  embeddable attributes. Embeddables may also be used as map keys and map values. Embedded
  objects are not sharable across persistent entities. Attributeing
  to share an embedded object semantics.
  

  
  
  
  
• Question 16. Can the Embeddable class contain another Embeddable class?
  
  Answer

  Yes maybe
  
  Java Persistence 2.1. Chapter 2.5
  
  

  Original

  An embeddable class can be used to constitute an embeddable class.An embeddable class can be used.
  

  
  
  
  
• Question 17. Can the Embeddable class contain relationships with other Entity or Entity collections? If so, then are there any restrictions on such relationships?
  
  Answer

  Maybe, but only if such a class is not used as the primary key or the map key.
  
  Java Persistence 2.1. Chapter 2.5
  

  Original

  An embeddable class may contain a relationship to an entity or collection of entities. There are no instantiations and there is no need for a persistent identity. An embeddable class
  

  
  
  
  
• Question 18. What requirements does JPA set for Embeddable classes?
  
  Answer

  1. Such classes must satisfy the same rules as the Entity classes, except that they do not have to contain a primary key and be marked with the Entity annotation (see question 10),
  2. The Embeddable class must be annotated with the Embeddable or described in the XML configuration file JPA,
  
  Java Persistence 2.1. Chapter 2.5
  

  Original

  It is not necessary to note that it is not necessary. Embeddable classes must be annotated as Embeddable or denoted in XML descriptor as such.
  

  
  
  
  
• Question 19. What types of relationships (relationship) between Entity do you know (list eight types, or specify four types of connections, each of which can be further divided into two types)?
  
  Answer

  The following four types of links exist.
  1. OneToOne (one to one relationship, that is, one Entity object can be associated with no more than one object of another Entity),
  2. OneToMany (one-to-many connection, one Entity object may be associated with a whole collection of other Entity),
  3. ManyToOne (many to one connection, feedback for OneToMany),
  4. ManyToMany (many to many connections)
  
  Each of which can be divided into two types:
  1. Bidirectional
  2. Unidirectional
  
  Bidirectional - link to the link is set for all Entity, that is, in the case of OneToOne AB, Entity A has a link to Entity B, Entity B has a link to Entity A, Entity A is considered the owner of this link (this is important for cases of cascading data deletion, then deleting A will also remove B, but not vice versa).
  
  Undirectional- link to the link is established only on one side, that is, in the case of OneToOne AB, only Entity A will have a link to Entity B, while Entity B will not have a link to A.
  
  Java Persistence 2.1. Chapter 2.9
  

  Original

  Relationships can be one-to-one, one-to-many, many-to-one, or many-to-many. Relationships are polymorphic.
  If you are a subject of a referencing entity, you’ll have to make one of the following relationships: OneToOne, OneToMany, ManyToOne, ManyToMany. Specify the target type (eg,
  where it is necessary to select the entity. [19] Equivalent XML elements may be used to complete the mapping annotations.
  These common mirror practices in relational database schema modeling. You must be able to provide an easy-of-development facility. This is
  described in Section 2.10, “Relationship Mapping Defaults”.
  Relationships may be bidirectional or unidirectional. A bidirectional relationship is both an owning side and an inverse (non-owning) side. A unidirectional relationship has only an owning side. It’s not a problem.
  

  
  
  
  
• Question 20. What is a mapped superclass?
  
  Answer

  Mapped Superclass is a class from which Entity is inherited, it may contain JPA annotations, however such a class is not Entity, it does not have to fulfill all the requirements set for Entity (for example, it may not contain a primary key). Such a class cannot be used in EntityManager or Query operations. Such a class should be marked with the MappedSuperclass annotation or described in the xml file accordingly.
  
  Java Persistence 2.1. Chapter 2.2
  

  Examples

  Examples on github : 1 2 3
  
  Example: Concrete class as a mapped superclass
  

  @MappedSuperclass public class Employee { @Id protected Integer empId; @Version protected Integer version; @ManyToOne @JoinColumn(name="ADDR") protected Address address; public Integer getEmpId() { ... } public void setEmpId(Integer id) { ... } public Address getAddress() { ... } public void setAddress(Address addr) { ... } } // Default table is FTEMPLOYEE table @Entity public class FTEmployee extends Employee { // Inherited empId field mapped to FTEMPLOYEE.EMPID // Inherited version field mapped to FTEMPLOYEE.VERSION // Inherited address field mapped to FTEMPLOYEE.ADDR fk // Defaults to FTEMPLOYEE.SALARY protected Integer salary; public FTEmployee() {} public Integer getSalary() { ... } public void setSalary(Integer salary) { ... } } @Entity @Table(name="PT_EMP") @AssociationOverride(name="address", joincolumns=@JoinColumn(name="ADDR_ID")) public class PartTimeEmployee extends Employee { // Inherited empId field mapped to PT_EMP.EMPID // Inherited version field mapped to PT_EMP.VERSION // address field mapping overridden to PT_EMP.ADDR_ID fk @Column(name="WAGE") protected Float hourlyWage; public PartTimeEmployee() {} public Float getHourlyWage() { ... } public void setHourlyWage(Float wage) { ... } } 

  
  

  
  

  Original

  It provides a persistent entity state and mapping information
  but which is not itself an entity. Typically, the mapped superclass is to define state
  mapping information that is common to multiple entity classes.
  It is not a queryable case.
  EntityManager or Query operations. Mars superclass must
  be unidirectional.
  Both mapped superclasses. The mappedsuperclass
  annotation (or mapped-superclass XML descriptor element) is used to designate a
  mapped superclass.
  A mapped superclass has been defined as a separate table for it. Its mapping information
  that it is from it.
  A mapped superclass can be mapped it can be mapped
  mappings will be used for the mapped superclass itself. When
  the mapping will be applied to the subclasses. Mapping
  information can be overridden in such subclasses by using the AttributeOverride and
  Association Override annotations or corresponding XML elements.
  A mapped superclass is defined as a mapped superclass.
  The following is a mapped superclass.
  

  
  
  
  
• Question 21. What are the three types of Inheritance Mapping Strategies described in JPA?
  
  Answer

  JPA describes three Inheritance Mapping Strategies, that is, how JPA will work with the classes inherited by Entity:
  1) one table for the entire inheritance hierarchy ( a single table per class hierarchy ) - all enity, with all heirs are written into one table, a special column “discriminator column” is defined to identify the type of entity. For example, if there is an entity Animals with the descendant classes Cats and Dogs, with such a strategy, all entities are recorded in the Animals table, but they have an additional column, animalType, in which the value “cat” or “dog” is written accordingly. The downside is that in the general table, all fields unique for each of the descendant classes will be created, which will be empty for all other descendant classes. For example, in the table of animals, there will be the speed of climbing a tree from cats and whether the dog can bring sneakers from dogs, which will always be null for a dog and cat, respectively.
  
  2) unifying strategy ( joined subclass strategy ) - in this strategy, each enity class stores data in its own table, but only unique columns (not inherited from ancestor classes) and the primary key, and all inherited columns are written into ancestor class tables, additionally a relationship is established between these tables, for example, in the case of the Animals classes (see above), there will be three tables of animals, cats, dogs, and only the key and climbing speed will be recorded in cats, in dogs - the key and whether the dog can bring a stick , and in animals all the rest of the data of cats and dogs are c links th to the appropriate table. The downside is the performance loss from joining tables (join) for any operations.
  
  3) one table for each class ( table per concrete class strategy ) - everything is simple, each separate class-successor has its own table, i.e. for cats and dogs (see above), all data will be recorded simply in the tables cats and dogs as if they did not have a common superclass at all. The downside is poor support for polymorphism (polymorphic relationships) and the fact that selecting all the classes in the hierarchy will require a large number of separate sql queries or using a UNION query.
  
  To set the inheritance strategy, use the Inheritance annotation (or corresponding blocks
  Java Persistence 2.1. Chapter 2.12 , J7EE javadoc
  
  

  Examples

  Examples on github : TABLE_PER_CLASS: 1 2 3 , JOINED: 1 2 3 , SINGLE_TABLE: 1 2 3
  
  

   @Entity @Inheritance(strategy=JOINED) public class Customer { ... } @Entity public class ValuedCustomer extends Customer { ... } 

  
  

  
  

  Original

  Hierarchy to a relational
  database:
  • a single table per class hierarchy
  • subclass are mapped to a separate
  it is not a matter of instantiate
  the subclass.
  • a table per concrete entity class
  

  
  
  
  
• Question 22. What are the two types of fetch strategies in JPA do you know?
  
  Answer

  JPA describes two types of fetch strategy:
  1) LAZY - these fields will be loaded only during the first access to this field,
  2) EAGER - these fields will be loaded immediately,
  
  Java Persistence 2.1. Chapter 11.1.6 J7EE javadoc
  
  

  Original

  The EAGER Strategy
  be eagerly fetched. The lazy strategy is a hint to the persistence provider
  entity should be fetched lazily when it is first accessed. The implementation is permitted to eagerly
  fetch associations for which the lazy strategy hint has been specified.
  

  
  
  
  

Basic Entity Operations

• Question 23. What is EntityManager and what are its main functions you can list?
  
  Answer

  EntityManager is an interface that describes the API for all major Enitity operations, data retrieval, and other JPA entities. Essentially the main API for working with JPA. Basic operations:
  1) For operations on Entity: persist (add Entity under JPA control), merge (update), remove (delete), refresh (update data), detach (remove from control JPA), lock (block Enity from changes in other threads) ,
  2) Get data: find (find and get Entity), createQuery, createNamedQuery, createNativeQuery, contains, createNamedStoredProcedureQuery, createStoredProcedureQuery
  3) Getting other JPA entities: getTransaction, getEntityManagerFactory, getCriteriaBuilder, getMetamodel, getDelegate
  4) Working with EntityGraph: createEntityGraph, getEntityGraph
  4) General operations on EntityManager or all Entities: close, isOpen, getProperties, setProperty, clear
  
  Java Persistence 2.1. Chapter 3.1.1 J7EE javadoc
  

  Examples

  Examples on github :
  1) operations: persist 1 , persist 2 , persist 3 merge , remove , detach , detach 2
  2) search: find 1 , find 2 , find 3 , createQuery 1 createQuery 2 createNativeQuery 1 createNativeQuery 2 createStoredProcedureQuery createNamedQuery
  3) EntityGraph work: 1 , 2 , 3 4
  
  

  
  

  Original

  Interface used to interact with the persistence context.
  An EntityManager instance is associated with a persistence context. There is a unique entity instance. Lifecycle are managed. The EntityManager API is used to create and remove objects.
  
  EntityManager instance is defined by a persistence unit. It has been established that it has been established that it can be used for a single database.
  

  
  
  
  
• Question 24. What are the four statuses of the Entity (Entity Instance's Life Cycle) object life cycle you can list?
  
  Answer

  An Entity object has four lifecycle status: new, managed, detached, or removed. Their description
  1) new - the object has been created, but has not yet generated primary keys and is not yet stored in the database,
  2) managed - the object is created, managed by JPA, has generated primary keys,
  3) detached - the object was created, but not managed (or no longer managed) by JPA,
  4) removed - the object is created, controlled by JPA, but will be deleted after commit'a transaction.
  
  Java Persistence 2.1. Chapter 3.2
  
  

  Original

  Can be characterized as being new, managed, detached, or removed.
  
  • is not associated with a persistence context.
  This is currently associated with a persistence context.
  This is not a case of association with a persistence context.
  • If you want to make a statement, you can’t get it.
  

  
  
  
  
• Question 25. How does the operation persist on Entity objects of each of the four statuses?
  
  Answer

  1) If the status is Entity new, then it changes to managed and the object will be saved to the database when a transaction is committed or as a result of flush operations,
  2) If the status is already managed, the operation is ignored, but dependent Entity can change the status to managed if they have annotations of cascading changes,
  3) If the status is removed, then it changes to managed,
  4) If the status is detached, exception will be thrown out immediately or on the commit stage of the transaction,
  
  Java Persistence 2.1. Chapter 3.2.2
  

  Original

  • If X is a new entity, it becomes managed. The entity X will be entered into the database at or
  before the transaction.
  • If X is a preexisting managed entity, it is ignored by the persist operation. However, the persist
  if it is referenced by X, if
  entities are annotated with the cascade = PERSIST or cascade = ALL annotation element
  value or specified with the equivalent XML descriptor element.
  • If X is a removed entity, it becomes managed.
  • If X is a detached object, the EntityExistsException may be thrown when the persist
  operation is invoked, or the EntityExistsException or another PersistenceException
  may be thrown at flush or commit time.
  • For all entities Y has been annotated
  with the cascade element value cascade = PERSIST or cascade = ALL, the persist
  operation is applied to Y
  

  
  
  
  
• Question 26. How does the remove operation affect Entity objects in each of the four statuses?
  
  Answer

  1) If the status is Entity new, the operation is ignored, however dependent Entity can change the status to removed, if they have cascading change annotations and they have managed status,
  2) If the status is managed, then the status changes to removed and the entry object in the database will be deleted when the transaction is committed (remove operations will also occur for all cascade-dependent objects),
  3) If the status is removed, then the operation is ignored,
  4) If the status is detached, exception will be thrown out immediately or on the commit stage of the transaction,
  
  Java Persistence 2.1. Chapter 3.2.3
  

  Original

  • If X is a new entity, it is ignored by the remove operation. However, the remove operation is
  cascaded to entities referenced by X, if this relationship is annotated
  with the cascade = REMOVE or cascade = ALL annotation element value.
  • If it is a managed entity, it can be removed. The remove operation
  if it is referenced by X, if these relationships
  is annotated with the cascade = REMOVE or cascade = ALL annotation element value.
  • If X is a detached entity, an IllegalArgumentException will
  operation (or the transaction commit will fail).
  • If it is removed, it is ignored by the remove operation.
  • The removed entity X.
  result of the flush operation.
  

  
  
  
  
• Question 27. How does the operation merge affect the Entity objects of each of the four statuses?
  
  Answer

  1) If the status is detached, then either the data will be copied into the existing managed entity with the same primary key, or a new managed one is created into which the data is copied,
  1) If the status is Entity new, then a new managed entity will be created in which the data of the past object will be copied,
  2) If the status is managed, the operation is ignored, but the operation merge will work on the cascade-dependent Entity, if their status is not managed,
  3) If the status is removed, the exception will be thrown immediately or at the commit stage of the transaction,
  
  Java Persistence 2.1. Chapter 3.2.7.1
  

  Original

  • If X is a detached entity, X is a pre-existing managed entity.
  X 'of X is created.
  • If X is a new entity instance, it’s created
  copied into the new managed entity instance X '.
  • If X is a removed entity of an IllegalArgumentException will be thrown by
  merge operation (or the transaction commit will fail).
  • If X is a managed entity, it is ignored.
  if these relationships have been annotated
  with the cascade element value cascade = MERGE or cascade = ALL annotation.
  • For all entities Y referenced by the cascade element value
  cascade = MERGE or cascade = ALL, Y is merged recursively as Y '. For all such Y referenced
  by X, X 'is set to reference Y'. (This is the same object as
  X '.)
  • If X is an entity merged to X, with a reference to another entity Y, where cascade = MERGE
  or cascade = ALL is not specified, then
  the same persistent identity as the Y.
  

  
  
  
  
• Question 28. How does the refresh operation affect the Entity objects of each of the four statuses?
  
  Answer

  1) If the status is Entity managed, then as a result of the operation all changes from the database of this Entity will be restored, also a refresh of all cascade-dependent objects will occur,
  2) If the status is new, removed or detached, exception is thrown,
  
  Java Persistence 2.1. Chapter 3.2.5
  

  Original

  • If you’re refreshed from the database, overwriting changes
  made to the entity, if any. The refresh operation is cascaded to entities referenced by X if the
  relationship with the cascade = REFRESH or
  cascade = ALL annotation element value.
  • If X is a new, detached, or removed entity, the IllegalArgumentException is thrown.
  

  
  
  
  
• Question 29. How does the detach operation affect the Entity objects of each of the four statuses?
  
  Answer

  1) If the status is Entity managed or removed, then as a result of the operation, the status of Entity (and all cascade-dependent objects) will become detached.
  2) If the status is new or detached, then the operation is ignored,
  
  Java Persistence 2.1. Chapter 3.2.6
  

  Original

  • If X is a managed entity, it becomes detached. The detach operation
  if it is referenced by X
  annotated with the cascade = DETACH or cascade = ALL annotation element value. Entities
  which previously referenced X will continue to reference X.
  • If X is a new or detached entity, it is ignored by the detach operation.
  • If it is a removed entity, it becomes a detached object. The detach operation
  if it is referenced by X
  annotated with the cascade = DETACH or cascade = ALL annotation element value. Entities
  X. Portable applications should not be referenced.
  pass away to further EntityManager
  operations.
  

  
  
  
  

JPA annotations

• Question 30. What is the Basic annotation for?
  
  Answer

  Basic - indicates the simplest type of data mapping on a database table column. Also in the annotation parameters you can specify fetch field access strategy and whether this field is mandatory or not.

  Examples

  Github examples: 1 2 3 4
  

   Example 1: @Basic protected String name; Example 2: @Basic(fetch=LAZY) protected String getName() { return name; } 

  
  

  Original

  The basic annotation is a simplest type of mapping to a database column. The basic annotation
  it can be applied to the following types: Java primitive
  types, wrappers of the primitive types, 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 [], Byte [], char [], Character [],
  enums, and any other type that implements Serializable. A
  

  
  
  
  
• Question 31. What is the Access annotation for?
  
  Answer

  It defines the access type for an entity class, superclass, embeddable, or individual attributes, that is, how JPA will refer to entity attributes, like class fields (FIELD) or class properties (PROPERTY) that have getters (getter) and setters.
  
  Java Persistence 2.1. Chapter 11.1.1
  
  

  Original

  It is an example of a class mapped superclass or embeddable class.
  

  
  
  
  
• Question 32. What annotations can overlap connections (override entity relationship) or attributes inherited from the superclass, or specified in the embeddable class when using this embeddable class in one of the entity classes and not overlapping in the others?
  
  Answer

  There are four annotations for this overlap:
  1. AttributeOverride to override the fields, properties and primary keys,
  2. AttributeOverrides can similarly overlap fields, properties and primary keys with multiple values,
  3. AssociationOverride to override the entity relationship,
  4. AssociationOverrides to overlap multiple relationships,
  
  Java Persistence 2.1. Chapter 11.1.2-11.1.5
  
  

  Original

  The Association Override annotation is a mapping for an entity entity.
  

  
  

  Examples (AssociationOverride)

  Example 1:
  

   @MappedSuperclass public class Employee { @Id protected Integer id; @Version protected Integer version; @ManyToOne protected Address address; public Integer getId() { ... } public void setId(Integer id) { ... } public Address getAddress() { ... } public void setAddress(Address address) { ... } } @Entity @AssociationOverride(name="address", joinColumns=@JoinColumn(name="ADDR_ID")) public class PartTimeEmployee extends Employee { // address field mapping overridden to ADDR_ID foreign key @Column(name="WAGE") protected Float hourlyWage; public Float getHourlyWage() { ... } public void setHourlyWage(Float wage) { ... } } 

  
  
  Example 2: Overriding the mapping for the phoneNumbers relationship in the ContactInfo
  embeddable class.
  

   @Entity public class Employee { @Id int id; @AssociationOverride( name="phoneNumbers", joinTable=@JoinTable( name="EMPPHONES", joinColumns=@JoinColumn(name="EMP"), inverseJoinColumns=@JoinColumn(name="PHONE") ) ) @Embedded ContactInfo contactInfo; ... } @Embeddable public class ContactInfo { @ManyToOne Address address; // Unidirectional @ManyToMany(targetEntity=PhoneNumber.class) List phoneNumbers; } @Entity public class PhoneNumber { @Id int number; @ManyToMany(mappedBy="contactInfo.phoneNumbers") Collection<Employee> employees; } 

  
  

  
  
  
  
• Question 33. What annotation can I manage JPA caching for this Entity?
  
  Answer

  Cacheable - allows you to enable or disable the use of the second-level cache (second-level cache) for this Entity (if the JPA provider supports caching and cache settings (second-level cache) are ENABLE_SELECTIVE or DISABLE_SELECTIVE, see question 41). Note that the property is inherited and if it is not blocked by the heirs, then caching will change for them too.
  

  Examples

  Github examples: 1 2 3 4
  

  
  

  Original

  If caching is enabled, it should be cached.
  the value of the persistence.xml shared-cache-mode element is ENABLE_SELECTIVE or
  DISABLE_SELECTIVE. The value of the Cacheable annotation is inherited by subclasses; it can be
  overridden by specifying Cacheable on a subclass.
  

   @Target({TYPE}) @Retention(RUNTIME) public @interface Cacheable { boolean value() default true; } 

  
  It must be cached by the provider.
  If the shared-cache-mode element is not specified in the persistence.xml file and the
  javax.persistence.sharedCache.mode property is not specified when the entity manager
  The semantics of the Cacheable annotation are undefined.
  

  
  
  
  
• Question 34. What annotations are used to set the basic conversion class of the attribute Entity to another type when saving / retrieving data from their database (for example, work with the attribute of an Entity boolean type, but save it as a number to the database)?
  
  Answer

  Convert and Converts - allow you to specify a class for converting the Basic attribute Entity to another type (Converts - allow you to specify several conversion classes). Classes for conversion must implement the AttributeConverter interface and may be marked (but not required) by the Converter annotation.
  
  For details, see Javadoc 7ee .
  

  Examples

  Examples on github : 1 2 3
  

   Example 1: Convert a basic attribute @Converter public class BooleanToIntegerConverter implements AttributeConverter<Boolean, Integer> { ... } @Entity public class Employee { @Id long id; @Convert(BooleanToIntegerConverter.class) boolean fullTime; ... } Example 2: Auto-apply conversion of a basic attribute @Converter(autoApply=true) public class EmployeeDateConverter implements AttributeConverter<com.acme.EmployeeDate, java.sql.Date> { ... } @Entity public class Employee { @Id long id; ... // EmployeeDateConverter is applied automatically EmployeeDate startDate; } Example 3: Disable conversion in the presence of an autoapply converter @Convert(disableConversion=true) EmployeeDate lastReview; Example 4: Apply a converter to an element collection of basic type @ElementCollection // applies to each element in the collection @Convert(NameConverter.class) List<String> names; Example 5: Apply a converter to an element collection that is a map or basic values. The converter is applied to the map value. @ElementCollection @Convert(EmployeeNameConverter.class) Map<String, String> responsibilities; Example 6: Apply a converter to a map key of basic type @OneToMany @Convert(converter=ResponsibilityCodeConverter.class, attributeName="key") Map<String, Employee> responsibilities; Example 7: Apply a converter to an embeddable attribute @Embedded @Convert(converter=CountryConverter.class, attributeName="country") Address address; Example 8: Apply a converter to a nested embeddable attribute @Embedded @Convert(converter=CityConverter.class, attributeName="region.city") Address address; Example 9: Apply a converter to a nested attribute of an embeddable that is a map key of an element collection @Entity public class PropertyRecord { ... @Convert(name="key.region.city", converter=CityConverter.class) @ElementCollection Map<Address, PropertyInfo> parcels; } Example 10: Apply a converter to an embeddable that is a map key for a relationship @OneToMany @Convert(attributeName="key.jobType", converter=ResponsibilityTypeConverter.class) Map<Responsibility, Employee> responsibilities; Example 11: Override conversion mappings for attributes inherited from a mapped superclass @Entity @Converts({ @Convert(attributeName="startDate", converter=DateConverter.class), @Convert(attributeName="endDate", converter=DateConverter.class)}) public class FullTimeEmployee extends GenericEmployee { ... } 

  
  

  
  
  
  
• Question 35. What annotation can be used to define a class, the methods of which should be executed with certain JPA operations on the Enitity or Mapped Superclass data (such as deletion, data modification, etc.)?
  
  Answer

  The EntityListeners annotation allows you to specify the Listener class, which will contain event handling methods (callback methods) defined by the Entity or Mapped Superclass.
  
  For details, see Javadoc 7ee .
  

  Examples

  Examples on github : 1 2 3
  

   @Entity @EntityListeners(com.acme.AlertMonitor.class) public class Account { Long accountId; Integer balance; boolean preferred; @Id public Long getAccountId() { ... } ... public Integer getBalance() { ... } ... @Transient // because status depends upon non-persistent context public boolean isPreferred() { ... } ... public void deposit(Integer amount) { ... } public Integer withdraw(Integer amount) throws NSFException {... } @PrePersist protected void validateCreate() { if (getBalance() < MIN_REQUIRED_BALANCE) throw new AccountException("Insufficient balance to open an account"); } @PostLoad protected void adjustPreferredStatus() { preferred = (getBalance() >= AccountManager.getPreferredStatusLevel()); } } public class AlertMonitor { @PostPersist public void newAccountAlert(Account acct) { Alerts.sendMarketingInfo(acct.getAccountId(), acct.getBalance()); } } 

  
  

  
  
  
  
• Question 36. What are the callback methods in JPA for? To which entities do callback method annotations apply? List seven callback methods (or the same annotations of callback methods)
  
  Answer

  Callback methods are used to call on certain Entity events (that is, add processing, for example, deletion of Entity methods by JPA), can be added to the entity class, to the mapped superclass, or to the callback listener class specified by the EntityListeners annotation (see previous question). There are seven callback methods (and annotations with the same names):
  
  1) PrePersist
  2) PostPersist
  3) PreRemove
  4) PostRemove
  5) PreUpdate
  6) PostUpdate
  7) PostLoad
  
  , Javadoc 7ee JPA2.1 3.5.2
  
  

  Examples

  github: PrePersist PostPersist PreRemove PostUpdate
  PostLoad
  

   @Entity @EntityListeners(com.acme.AlertMonitor.class) public class Account { Long accountId; Integer balance; boolean preferred; @Id public Long getAccountId() { ... } ... public Integer getBalance() { ... } ... @Transient // because status depends upon non-persistent context public boolean isPreferred() { ... } ... public void deposit(Integer amount) { ... } public Integer withdraw(Integer amount) throws NSFException {... } @PrePersist protected void validateCreate() { if (getBalance() < MIN_REQUIRED_BALANCE) throw new AccountException("Insufficient balance to open an account"); } @PostLoad protected void adjustPreferredStatus() { preferred = (getBalance() >= AccountManager.getPreferredStatusLevel()); } } public class AlertMonitor { @PostPersist public void newAccountAlert(Account acct) { Alerts.sendMarketingInfo(acct.getAccountId(), acct.getBalance()); } } 

  
  

  
  
  
  
• 37. Entity?
  
  Answer

  OrderBy OrderColumn
  
  , Javadoc 7ee JPA2.1 11.1.42
  
  

  Examples

   Example 1: @Entity public class Course { ... @ManyToMany @OrderBy("lastname ASC") public List<Student> getStudents() {...}; ... } Example 2: @Entity public class Student { ... @ManyToMany(mappedBy="students") @OrderBy // PK is assumed public List<Course> getCourses() {...}; ... } Example 3: @Entity public class Person { ... @ElementCollection @OrderBy("zipcode.zip, zipcode.plusFour") public Set<Address> getResidences() {...}; ... } 

  
  

  
  
  
  
• 38. Entity (property or field is not persistent)?
  
  Answer

  Transient
  
  , Javadoc 7ee JPA2.1 11.1.52
  
  

  Example

   @Entity public class Employee { @Id int id; @Transient User currentUser; ... } 

  
  

  
  
  
  

JPA

• 39. (lock) JPA ( enum LockModeType JPA)?
  
  Answer

  JPA , ( , ):
  
  1) NONE —
  2) OPTIMISTIC ( READ, JPA 1) — ,
  3) OPTIMISTIC_FORCE_INCREMENT ( WRITE, JPA 1) — ,
  4) PESSIMISTIC_READ — ,
  5) PESSIMISTIC_WRITE — ( ),
  6) PESSIMISTIC_FORCE_INCREMENT — ( ) ,
  
  , Javadoc 7ee .
  
  
  
• 40. (cache) JPA ?
  
  Answer

  JPA (cache):
  1) first-level cache ( ) — ,
  2) second-level cache ( ) — . JPA , . , .
  
  , JPA 2.1 specification, 3.9 Caching
  

  Original

  This specification supports the use of a second-level cache by the persistence provider. The second-level
  cache, if used, underlies the persistence context, and is largely transparent to the application.
  A second-level cache is typically used to enhance performance. Use of a cache, however, may have
  consequences in terms of the up-to-dateness of the data seen by the application, resulting in “stale
  reads”. A stale read is defined as the reading of entities or entity state that is older than the point at
  which the persistence context was started.
  

  
  
  
  
• 41. second-level cache ( ) JPA shared-cache-mode persistence.xml?
  
  Answer

  JPA shared-cache-mode persistence.xml, second-level cache:
  1) ALL — Entity ,
  2) NONE — Entity,
  3) ENABLE_SELECTIVE — Entity, Cacheable(true) xml , ,
  4) DISABLE_SELECTIVE — Entity, Cacheable(false) xml
  5) UNSPECIFIED — , JPA ,
  
  , JPA 2.1 specification, 3.9 Caching
  

  Original

  The shared-cache-mode element has five possible values: ALL, NONE, ENABLE_SELECTIVE,
  DISABLE_SELECTIVE, UNSPECIFIED.
  

  
  
  
  
• 42. fetch Entity (query) (find), Enity fetchType = LAZY, EAGER ?
  
  Answer

  EntityGraph API, : NamedEntityGraph Entity, EntityGraph , fetchType EAGER, hits find. fetchType Entity , . property EntityGraph hit:
  1) javax.persistence.fetchgraph — EntityGraph fetchType EAGER, LAZY
  2) javax.persistence.loadgraph — EntityGraph fetchType EAGER, fetchType ( , EntityGraph, fetchType EAGER, EAGER)
  
  NamedSubgraph fetchType Entity.
  
  

  Examples

   //  Entity  EntityGraph @Entity @Table(name = "order") @Named(name = "graphOrderItems", attributeNodes = @NamedAttributeNode(attributeNodes = "items") ) public class Order implements Serializable { ... @OneToMany(mappedBy = "order", fetch = FetchType.LAZY) private Set<Item> items = new HashSet<Item>(); @OneToMany(mappedBy = "order", fetch = FetchType.EAGER) private Set<Features> features = new HashSet<Features>(); @OneToMany(mappedBy = "order", fetch = FetchType.LAZY) private Set<Comment> comments = new HashSet<Comment>(); ... //    c javax.persistence.fetchgraph .. EntityGraph graph = this.em.getEntityGraph("graphOrderItems"); Map hints = new HashMap(); hints.put("javax.persistence.fetchgraph", graph); return this.em.find(Order.class, orderId, hints); // items      fetchType = EAGER,  features  comments  fetchType = LAZY //    c javax.persistence.loadgraph .. EntityGraph graph = this.em.getEntityGraph("graphOrderItems"); Map hints = new HashMap(); hints.put("javax.persistence.loadgraph", graph); return this.em.find(Order.class, orderId, hints); // items  features      fetchType = EAGER,  comments    fetchType = LAZY 

  
  
  

  , JPA 2.1 specification, 3.7 EntityGraph
  
  

  Original

  An entity graph can be used with the find method or as a query hint to override or augment FetchType semantics. The standard properties javax.persistence.fetchgraph and javax.persistence.loadgraph are used to specify such graphs to queries and find operations
  

  
  
  
  
• 43. ( Entity , Entity ..)?
  
  Answer

  (second level cache) JPA Cache , (second level cache), JPA, . getCache EntityManagerFactory.
  
  , JPA 2.1 specification, 7.10 Cache Interface
  

  Original

  The Cache interface provides basic functionality over the persistence provider's second level cache, if used.
  

  
  
  
  
• 44. JPA ( Entity , Embeddable Managed ..)?
  
  Answer

  JPA Metamodel. getMetamodel EntityManagerFactory EntityManager.
  
  , JPA 2.1 specification, 5 Metamodel API
  

  Original

  This specification provides a set of interfaces for dynamically accessing the metamodel corresponding
  to the managed classes of a persistence unit.
  

  
  
  
  
• 45. JPQL (Java Persistence query language) SQL?
  
  Answer

  JPQL (Java Persistence query language) , SQL, , Entity . Entity, . SQL JPQL (. ). JPQL SQL: KEY ( Map'), VALUE ( Map'), TREAT ( -, downcasting), ENTRY ..
  
  , JPA 2.1 specification, Chapter 4 Query Language
  

  Original

  The Java Persistence query language is a string-based query language used to define queries over entities
  and their persistent state. It enables the application developer to specify the semantics of queries in
  a portable way, independent of the particular database schema in use in an enterprise environment. The
  full range of the language may be used in both static and dynamic queries
  

  
  
  
  
• 46. (polymorphism) JPQL (Java Persistence query language) «»?
  
  Answer

  SQL JPQL , Entity Entity, -, (, select * from Animal, Animal, Cat Dog, Animal). TYPE where ( select * from Animal a where TYPE(a) IN (Animal, Cat) Dog).
  
  , JPA 2.1 specification, Chapter 4 Query Language
  

  Original

  Java Persistence queries are automatically polymorphic. An entity type expression can be used to restrict query polymorphism. The TYPE operator returns the exact type of the argument.
  

  
  
  
  
• 47. Criteria API ?
  
  Answer

  Criteria API , JPQL (Java Persistence query language), , :
  

   CriteriaBuilder cb = ... CriteriaQuery<Customer> q = cb.createQuery(Customer.class); Root<Customer> customer = q.from(Customer.class); q.select(customer); 

  
  
  , JPA 2.1 specification, Chapter 6 Criteria API
  

  Original

  The Java Persistence Criteria API is used to define queries through the construction of object-based
  query definition objects, rather than use of the string-based approach of the Java Persistence query language
  described in Chapter 4.
  

  
  
  
  

Hibernate 5.0 JPA 2.1 JPA 2.0 JPA 2.1

• 48. Entity Hibernate, Entity, JPA (. 10)?
  
  Answer

  
  1) public protected, package , , Java , ,
  2) JPA final , Hibernate , Proxy (lazy=false), , ( Proxy (proxyClass=.class) )
  
  , hibernate 5.0 manual
  
  
  
• 49. Hibernate, JPA?
  
  Answer

  
  JPA Hibernate , implicit polymorphism.
  
  , hibernate 5.0 manual
  

  Original

  Hibernate supports the three basic inheritance mapping strategies:
  
  table per class hierarchy
  table per subclass
  table per concrete class
  In addition, Hibernate supports a fourth, slightly different kind of polymorphism:
  
  implicit polymorphism
  

  
  
  
  
• 50. JPA 2.1 JPA 2.0 ( - )?
  
  Answer

  
  JPA 2.1 :
  1) Entity Graphs — fetchType ,
  2) Converters — Entity ,
  3) DDL — , ,
  4) Stored Procedures — JPA,
  5) Criteria Update/Delete — bulk updates deletes, Criteria API,
  6) Unsynchronized persistence contexts — SynchronizationType,
  7) JPQL/Criteria API: , generic database functions, join ON clause, TREAT,
  8) (named queries)
  
  API JPA 2.1:
  1) EntityManager createStoredProcedureQuery, isJoinedToTransaction createQuery(CriteriaUpdate CriteriaDelete)
  2) AbstractQuery CommonAbstractCriteria, CriteriaUpdate, CriteriaDelete CommonAbstractCriteria,
  3) PersistenceProvider generateSchema ,
  4) EntityManagerFactory addNamedQuery, unwrap, addNamedEntityGraph, createEntityManager ( SynchronizationType)
  5) enum SynchronizationType, Entity Graphs, StoredProcedureQuery AttributeConverter ,
  
  , Java Persistence 2.1 Java Persistence 2.0