Thinking Beyond ORM in JPA

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Thinking Beyond ORM in JPA
Patrycja Wegrzynowicz
CTO
Yonita, Inc.
March 15, 2016
Please Stand By. This session will begin promptly at the time
indicated on the agenda. Thank You.

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

About Me
• 15+ professional experience
– Still an active developer!
• Author and speaker
– JavaOne, Devoxx, JavaZone, others
• Finalizing PhD in Computer Science
• Founder and CTO of Yonita
– Consulting plus automated tools for
detection of bugs in software
– Security, performance, databases
• Twitter @yonlabs
Oracle Confidential – Internal/Restricted/Highly Restricted
3

Outline
• Why?
– App-centric vs. data-centric
• What?
– Use cases and performance
• How?
– JPA (2.1)

Database

Database – The Mordor of Java Developers

Why? Different paradigms!
• One size doesn’t fit all!
• App-centric
– Java code drives database design
– One app accesses data
– CRUD more often than complex
queries
• Data-centric
– Database design drives Java code
– Several apps access data
– CRUD as often as complex queries

What? Use Cases

What? Performance

Legacy Systems

Legacy systems and Database-Level Abstraction
• Legacy systems
– It’s always worked that way!
– Database was all we had!
– We need to feed all those apps!
• Abstraction
– Views
– Stored procedures
– Triggers

Stored Procedures in JPA
• 2.0 and before
– Native queries to call stored procedures
– No OUT/INOUT parameters
– Database dependent CALL syntax
• 2.1
– EntityManager.createStoredProcedureQuery
– @NamedStoredProcedureQuery

Example: Stored Procedure
Result Set
-- MySQL
CREATE PROCEDURE GET_EMPLOYEES()
BEGIN
SELECT * FROM EMPLOYEES;
END

EntityManager API
// create and setup a stored procedure query
StoredProcedureQuery q = em.createStoredProcedureQuery("GET_EMPLOYEES", Employee.class);
// gather the results
List<Employee> list = (List<Employee>) q.getResultList();

EntityManager API
// gather the results, an implicit call to an execute method!

OUT Parameter
-- MySQL
CREATE PROCEDURE SUM_SALARIES(OUT TOTAL INT)
BEGIN
SELECT SUM(SALARY) INTO TOTAL
FROM EMPLOYEES;
END

EntityManager API
StoredProcedureQuery q = em.createStoredProcedureQuery("SUM_SALARIES");
q.registerStoredProcedureParameter("TOTAL", Integer.class, ParameterMode.OUT);
// execute the query...
q.execute();
// ...to obtain the output value
Integer total = (Integer) q.getOutputParameterValue("TOTAL");

All in One
-- MySQL
CREATE PROCEDURE GET_EMPLOYEES(
IN GIVEN_COUNTRY VARCHAR(255),
OUT TOTAL INT
)
BEGIN
SELECT SUM(SALARY) INTO TOTAL
FROM EMPLOYEES
WHERE COUNTRY = GIVEN_COUNTRY;
SELECT *
FROM EMPLOYEES
WHERE COUNTRY = GIVEN_COUNTRY;
END

EntityManager API
q.registerStoredProcedureParameter("COUNTRY", String.class, ParameterMode.IN);
// setup the parameters
q.setParameter("COUNTRY", "Poland");
// obtain the employees...
// ...and the output value

EntityManager API
StoredProcedureQuery q = em.createStoredProcedureQuery("GET_EMPLOYEES",Employee.class);
// obtain the employees
// do we need the execute call here?

EntityManager API
// first, an implicit call to execute
// ...then, we can safely obtain the output value 

EntityManager API
// what if we reorder the lines?

EntityManager API
// what if we reorder the lines?
// an implicit call to execute

EntityManager API
q = em.createStoredProcedureQuery("GET_EMPLOYEES", Employee.class);
// execute must be called before getOutputParameterValue
q.execute();

EntityManager API
q.execute();
// does it call execute once more?

EntityManager API
q.execute();
// an implicit call to execute only if not executed yet!

EntityManager API
// what about the order here?
// execute and retrieve the results
q.execute();

EntityManager API
// what if we switch the lines?
q.execute();

EntityManager API
// what about the order of the positional parameters?
q.registerStoredProcedureParameter(2, Integer.class, ParameterMode.OUT);
q.registerStoredProcedureParameter(1, String.class, ParameterMode.IN);
q.execute();

Annotation
@NamedStoredProcedureQuery {
name = "getEmployees",
procedureName = "GET_EMPLOYEES",
resultClasses = Employee.class,
parameters = {
@StoredProcedureParameter(name="COUNTRY", mode=ParameterMode.IN, type=String.class),
@StoredProcedureParameter(name="TOTAL", mode=ParameterMode.OUT, type=Integer.class)
}
}
@Entity
public class Employee {
// …
}

EntityManager API
StoredProcedureQuery q = em.createNamedStoredProcedureQuery("getEmployees");

EntityManager API
// no calls to registerStoredProcedureParameter

-- PostgreSQL
CREATE OR REPLACE FUNCTION GET_EMPLOYEES(
IN GIVEN_COUNTRY VARCHAR(255),
OUT TOTAL INT)
RETURNS REFCURSOR AS
$BODY$
DECLARE
EMPS REFCURSOR;
BEGIN
OPEN EMPS FOR SELECT * FROM EMPLOYEE WHERE COUNTRY = GIVEN_COUNTRY;
RETURN EMPS;
END;
$BODY$
LANGUAGE plpgsql

EntityManager API
q.registerStoredProcedureParameter(1, void.class, ParameterMode.REF_CURSOR);

Annotation
@NamedStoredProcedureQuery(
name = "getEmployees",
procedureName = "GET_EMPLOYEES",
resultClasses = Employee.class,
parameters = {
@StoredProcedureParameter(mode=ParameterMode.REF_CURSOR, type=void.class),
@StoredProcedureParameter(name="COUNTRY", mode=ParameterMode.IN, type=String.class)
}
)
@Entity
public class Employee {
// …
}

EntityManager API
StoredProcedureQuery q = em.createNamedStoredProcedureQuery(”getEmployees”);

EntityManager API
q.setParameter(2, "Poland");
// obtain the result

Stored Procedures in JPA 2.1
Wrap-up
• Annotation
– @NamedStoredProcedureQuery
• EntityManager API
– createStoredProcedureQuery
– registerStoredProcedureParameter
• Use cases
– Existing database
– Abstraction on database level (e.g., for several applications)
• Still differences between databases!
– Much smaller though

Reporting

Reporting Anti-Patterns
• Direct usage of an object-oriented domain model
• Too much data loaded
• Heavy processing on the Java side

Example

Employee Entity
@Entity public class Employee {
@Id @GeneratedValue
private Long id;
private String firstName;
private String lastName;
private BigDecimal salary;
@OneToOne @JoinColumn(name = "address_id")
private Address address;
@Temporal(TemporalType.DATE)
private Date startDate;
@Temporal(TemporalType.DATE)
private Date endDate;
@ManyToOne @JoinColumn(name = "manager_id")
private Employee manager;
// …
}

Sum of Salaries By Country
Select All (1)
TypedQuery<Employee> query = em.createQuery(
"SELECT e FROM Employee e", Employee.class);
List<Employee> list = query.getResultList();
// calculate sum of salaries by country
// map: country->sum
Map<String, BigDecimal> results = new HashMap<>();
for (Employee e : list) {
String country = e.getAddress().getCountry();
BigDecimal total = results.get(country);
if (total == null) total = BigDecimal.ZERO;
total = total.add(e.getSalary());
results.put(country, total);
}

Sum of Salaries by Country
Select Join Fetch (2)
TypedQuery<Employee> query = em.createQuery(
"SELECT e FROM Employee e
JOIN FETCH e.address", Employee.class);
List<Employee> list = query.getResultList();
for (Employee e : list) {
String country = e.getAddress().getCountry();
total = total.add(e.getSalary());
}

Projection (3)
Query query = em.createQuery(
"SELECT e.salary, e.address.country
FROM Employee e");
List<Object[]> list = (List<Object[]>) query.getResultList();
for (Object[] e : list) {
String country = (String) e[1];
total = total.add((BigDecimal) e[0]);
}

Aggregation JPQL (4)
"SELECT SUM(e.salary), e.address.country
FROM Employee e
GROUP BY e.address.country");
// already calculated!

Aggregation SQL (5)
Query query = em.createNativeQuery(
"SELECT SUM(e.salary), a.country
FROM employee e JOIN address a ON e.address_id = a.id
GROUP BY a.country");
// already calculated!

Comparison 1-5
100 000 employees, EclipseLink
MySQL PostgreSQL
Select all (1+N) (1) 25704ms 18120ms
Select join fetch (2)
Projection (3)
Aggregation SQL (5)

Comparison 1-5
MySQL PostgreSQL
Select all (1+N) (1) 25704ms 18120ms
Select join fetch (2) 6211ms 3954ms
Projection (3)
Aggregation SQL (5)

Comparison 1-5
MySQL PostgreSQL
Select all (1+N) (1) 25704ms 18120ms
Projection (3) 533ms 569ms
Aggregation SQL (5)

Comparison 1-5
MySQL PostgreSQL
Select all (1+N) (1) 25704ms 18120ms
Projection (3) 533ms 569ms
Aggregation JPQL (4) 410ms 380ms
Aggregation SQL (5) 380ms 409ms

MySQL vs. PostgreSQL
68
25704
6211
533 410 380
18120
3954
569 380 4090
5000
10000
15000
20000
25000
30000
Select all
(1+N) (1)
Select join
fetch (2)
Projection
(3)
Aggregation
JPQL (4)
Aggregation
SQL (5)
MySQL
PostgreSQL

Projection
JPQL -> Value Object
"SELECT new com.yonita.jpa.vo.EmployeeVO(e.salary, e.address.country)
FROM Employee e");
// The list of value objects
List<EmployeeVO> list = (List<EmployeeVO>) query.getResultList();

Projection
JPQL -> Value Object
"SELECT new com.yonita.jpa.CountryStatVO(
sum(e.salary), e.address.country)
FROM Employee e
GROUP BY e.address.country");
List<CountryStatVO> list = (List<CountryStatVO>) query.getResultList();

Projection
SQL -> Value Object
@SqlResultSetMapping(
name = "countryStatVO",
classes = {
@ConstructorResult(
targetClass = CountryStatVO.class,
columns = {
@ColumnResult(name = "ssum", type = BigDecimal.class),
@ColumnResult(name = "country", type = String.class)
})
}
)

Projection
SQL -> Value Object
Query query = em.createNativeQuery("countryStatVO");
List<CountryStatVO> list = (List<CountryStatVO>) query.getResultList();

Projection
Wrap-up
• JPA 2.0
– Only JPQL query to directly produce a value object!
• JPA 2.1
– JPQL and native queries to directly produce a value object!
• Managed entities
– Sync with database
– L1/L2 cache
• Use cases for Direct Value Object
– Reporting, statistics, history
– Read-only data, GUI data
• Performance
– No need for managed objects
– Rich (or fat) managed objects
– Subset of attributes required
– Gain speed
– Offload an app server

Aggregation
Wrap-up
• JPA 2.0
– Selected aggregation functions: COUNT, SUM, AVG, MIN, MAX
• JPA 2.1
– All function as supported by a database
– Call any database function with new FUNCTION keyword
• Database-specific aggregate functions
– MS SQL: STDEV, STDEVP, VAR, VARP,…
– MySQL: BIT_AND, BIT_OR, BIT_XOR,…
– Oracle: MEDIAN, PERCENTILE,…
– More…
• Use cases
– Reporting, statistics
– Performance
• Gain speed
• Offload an app server to a database!

Complex Queries

JPQL vs. SQL
• Column/table visibility
– JPA 2.0/2.1: Only mapped columns and tables
• Operations on sets
– UNION, INTERSECT, EXCEPT
– JPA 2.0/2.1: No support
• Nested fetch joins
– JPA 2.0: No support
– JPA 2.1: entity graphs for different fetching strategies
• ON
– JPA 2.0: No support
– JPA 2.1: Only on “connected entities”

JPQL vs. SQL
• Database functions
– Aggregate functions
– Conversion functions
– Extraction functions
– Manipulation functions
– Functions, functions, functions…
– JPA 2.0: Selected functions
– JPA 2.1: All functions

Helper Functions JPA 2.1
• String functions:
– CONCAT, SUBSTRING, TRIM, LOWER, UPPER, LENGTH, LOCATE
• Arithmetic functions:
– ABS, SQRT, MOD, SIZE, INDEX
• Date/time functions:
– CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP
• Aggregate functions:
– COUNT, SUM, MIN, MAX, AVG
• Invocation of predefined or user-defined functions:
– FUNCTION(function_name {, function_args}*)

Helper Functions JPA 2.1
• Invocation of predefined or user-defined functions:
– FUNCTION(function_name {, function_args}*)
– SELECT c
FROM Customer c
WHERE FUNCTION(‘hasGoodCredit’, c.balance, c.creditLimit)

JPA 2.1

Wrap-up
• JPA 2.1
– Stored procedures support
– Projections
• Direct value object for native queries
– Richer JPQL

Wrap-up
• JPA 2.1
– Projections
– Richer JPQL
• Performance

Wrap-up
• JPA 2.1
– Projections
– Richer JPQL
• Performance
– Don’t load if you don’t need

Wrap-up
• JPA 2.1
– Projections
– Richer JPQL
• Performance
– Don’t execute many small queries if you can execute one big query

Wrap-up
• JPA 2.1
– Projections
– Richer JPQL
• Performance
– Don’t execute many small queries if you can execute one big query
– Don’t calculate if a database can

A fool with a tool is still a fool!

Continuous Learning Paradigm
87

Q+A

Keep Learning with Training from Oracle University
89
• Hands-on training delivered in-class or online by
tenured instructors around the world
• New subscription-based learning services to give you
any-time access to training
• Certification programs to validate your skills
education.oracle.com

Thinking Beyond ORM in JPA

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (19)

Similaire à Thinking Beyond ORM in JPA

Similaire à Thinking Beyond ORM in JPA (20)

Plus de Patrycja Wegrzynowicz

Plus de Patrycja Wegrzynowicz (8)

Dernier

Dernier (20)

Thinking Beyond ORM in JPA