OK lets start, who am I ?

Nayden Gochev (a.k.a. JOKe) Java Spring Android Hybris GWT EJB JSF RMI JAX-RS Struts JMS JPA Hibernate C# ASP.NET TestStudio JustMock WCF JAX-WS EntityFramework RichFaces RadControls DataAccess MVC MbUnit WebForms JustCode Eclipse PHP JavaScript Objective-C ExtJS KendoUI jQuery UI jQuery TFS Spring MVC AngularJS

JPA Advanced Topics

Data Types and Converters String (char, char[]) VARCHAR (CHAR, VARCHAR2, CLOB, TEXT) Number (BigDecimal, BigInteger, Integer, Double, Long, Float, Short, Byte) NUMERIC (NUMBER, INT, LONG, FLOAT, DOUBLE) int, long, float, double, short, byte NUMERIC (NUMBER, INT, LONG, FLOAT, DOUBLE) byte[] VARBINARY (BINARY, BLOB) boolean (Boolean) BOOLEAN (BIT, SMALLINT, INT, NUMBER) java.util.Date, java.sql.Date, java.sql.Time, java.sql.Timestamp, java.util.Calendar TIMESTAMP (DATE, DATETIME) java.lang.Enum NUMERIC (VARCHAR, CHAR) java.util.Serializable VARBINARY (BINARY, BLOB)

Relationships Supported Relations in JPA are : OneToOne: In this relationship each entity has exactly one reference to the other entity and vice versa. OneToMany / ManyToOne: In this relationship one entity can have multiple child entities and each child entity belongs to one parent entity. ManyToMany: In this relationship multiple entites of one type can have multiple references to entities from the other type. Embedded: In this relationship the other entity is stored in the same table as the parent entity (i.e. we have two entites for one table). ElementCollection: This relationship is similar to the OneToMany relation but in contrast to it the referenced entity is an Embedded entity. This allows to define OneToMany relationships to simple objects that are stored in contrast to the “normal” Embedded relationship in another table.

OneToOne = "T_ID_CARD") public class IdCard { private Long public Long getId() { return id; } = "T_PERSON") public class Person {... private = "ID_CARD_ID") public IdCard getIdCard() { return idCard; }

= FetchType.EAGER) The value FetchType.EAGER is the default value and specifies that each time we load a person we also want to load the ID card. On the other hand we can specify that we only want to load the ID when we actually access it by calling = FetchType.LAZY)

OneToMany = "T_PHONE") public class Phone { private Long id; private Person public Long getId() { return id; = = "PERSON_ID") public Person getPerson() { return person; } = "T_PERSON") public class Person { private List phones = new = "person", fetch = FetchType.LAZY) public List getPhones() { return phones; }

ManyToMany = "T_PROJECT") public class Project { private Long id; private String title; private List geeks = new ArrayList (); public List getGeeks() { return geeks; } = "T_GEEK") public class Geek { … private List projects = name="T_GEEK_PROJECT", _ID", referencedColumnName="ID")}, ="PROJECT_ID", referencedColumnName="ID")}) public List getProjects() { return projects; }

Embedded / public class Period { private Date startDate; private Date ="START_DATE") public Date getStartDate() { return startDate; } public void setStartDate(Date startDate) { this.startDate = startDate; ="END_DATE") public Date getEndDate() { return endDate; } public void setEndDate(Date endDate) { this.endDate = endDate; }

Then to Use It private Period public Period getProjectPeriod() { return projectPeriod; } public void setProjectPeriod(Period projectPeriod) { this.projectPeriod = projectPeriod; }

@Embeddable Entities in One-to-Many Relations private List billingPeriods = new name="T_BILLING_PERIOD", ) public List getBillingPeriods() { return billingPeriods; } public void setBillingPeriods(List billingPeriods) { this.billingPeriods = billingPeriods; }

Inheritance SINGLE_TABLE This strategy maps all classes to one single table. It uses a DiscriminatorColumn. JOINED - separate table. Join is used when fetching entities which can be slower. TABLE_PER_CLASS - separate table but doesn't use JOIN, instead both (or more) tables contain all the information entity needs.

Single = "T_GEEK") public class Geek extends Person { private String favouriteProgrammingLanguage; private List projects = new ArrayList = "FAV_PROG_LANG") public String getFavouriteProgrammingLanguage() { return favouriteProgrammingLanguage; } public void setFavouriteProgrammingLanguage(String favouriteProgrammingLanguage) { this.favouriteProgrammingLanguage = favouriteProgrammingLanguage; }... } //In the database you will notice new column DTYPE sql> select * from t_person; DTYPE | ID | FIRST_NAME | LAST_NAME | FAV_PROG_LANG Person | 1 | Homer | Simpson | null Geek | 2 | Gavin | Coffee | Java Geek | 3 | Thomas | Micro | C# Geek | 4 | Christian | Cup | Java

@DiscriminatorColumn(name="PERSON_TYPE", discriminatorType = public class Person { … } //then same query will show this result: sql> select * from t_person; PERSON_TYPE | ID | FIRST_NAME | LAST_NAME | FAV_PROG_LANG | 1 | Homer | Simpson | null | 2 | Gavin | Coffee | Java | 3 | Thomas | Micro | C# | 4 | Christian | Cup | Java

Single inheritance ISSUES No class discriminator column (if you have OLD legacy database.. which doesn't have discriminator column.. then you need to use crazy stuff like DescriptorCustomizer(EclipseLink) DiscriminatorFormula (Hibernate) Non nullable attributes

JOINED = public class Person { … } //then same query will show this result: sql> select * from t_person; ID | FIRST_NAME | LAST_NAME 1 | Homer | Simpson 2 | Gavin | Coffee 3 | Thomas | Micro 4 | Christian | Cup (4 rows, 12 ms) sql> select * from t_geek; FAV_PROG_LANG | ID Java | 2 C# | 3 Java | 4 (3 rows, 7 ms)

JOINED inheritance ISSUES Poor query performance Do not have/want a table for every subclass

TABLE_PER_CLASS public abstract class Project private long public class LargeProject extends Project { private BigDecimal public class SmallProject extends Project { }

TABLE_PER_CLASS inheritance ISSUES Poor query performance - The main disadvantage to the table per class model is queries or relationships to the root or branch classes become expensive. Issues with ordering and joins Because table per class inheritance requires multiple queries, or unions, you cannot join to, fetch join, or traverse them in queries. Also when ordering is used the results will be ordered by class, then by the ordering.

Mapped Superclass Mapped superclass inheritance allows inheritance to be used in the object model, when it does not exist in the data model. It is similar to table per class inheritance, but does not allow querying, persisting, or relationships to the superclass. Its main purpose is to allow mappings information to be inherited by its subclasses. The subclasses are responsible for defining the table, id and other information, and can modify any of the inherited mappings

public abstract class Project private long private String @AttributeOverride(name="name", public class LargeProject extends Project { private BigDecimal public class SmallProject extends Project { }

Mapped Superclass Issues Cannot query, persist, or have relationships. You also cannot have a relationship to a mapped superclass

Criteria API CriteriaBuilder builder = entityManager.getCriteriaBuilder(); CriteriaQuery query = builder.createQuery(Person.class); Root personRoot = query.from(Person.class); query.where(builder.equal(personRoot.get("firstName"), "Homer")); List resultList = entityManager.createQuery(query).getResultList(); //or we can write query.where(builder.and( builder.equal(personRoot.get("firstName"), "Homer"), builder.equal(personRoot.get("lastName"), "Simpson"))); In general CriteriaQuery defines the following clauses and options: distinct(), from(), select(), multiselect(), where(), orderBy(), groupBy(), having(), subquery()

Contacts Blog : Facebook: Linkedin: Skype: joke.gochev GitHub :