Hibernate - JPA @luce 4

¿Qué deberíamos saber?
•

Relaciones simples @OneToMany y @ManyToOne

•

Cascades

•

Tipos de fetching

¿Qué vamos a ver?
•

Dudas?

•

El código está en github.

¿Qué vamos a ver?
•

Consultas

•

Entender la sesión...

Entidades y estados en
detalle

Entidades y estados en detalle

•

La sesión (y entityManager) hace varias cosas:
o Dirty Checking -> sólo actualizar las cosas que han cambiado.

o Actúa de caché de primer nivel -> sólo lee si no lo tiene en sesión
o Puede asegurar identidad de objetos
o Puede extender la conversación

Entendiendo el estado
Persistent

•

Para ver el estado Persistent...
o Cread un objeto (Pepe)
o Guardad (Pepe)
o Cambiad un valor del objeto (Lola) y no llamo a save/persist/update...
o Haced un commit
o En otra sesión o en la BD, leed el valor.

Qué pasa?
Se persiste el valor

•
•
•
•

Yo personalmente habría esperado leer Pepe.
No llamamos a update explícitamente
Hay 1 transacción de base de datos
Cuando hacemos un save() y un rollback() no recupera el estado del objeto
en Java (obviamente)
o get() -> recupero Pepe
o cambio a Lola
o rollback() -> en BD sigue Pepe
o mi modelo Java sigue poniendo Lola

•

Para ver el estado Persistent tras un get/load
o Recuperad un objeto de BD
o Cambiad un valor del objeto
o Haced un commit

Qué pasa?
-> Sí ha cambiado el valor.

•
•
•

Esta política se llama write-behind.
Implica que las entidades en estado PERSISTENT porque
o o se ha llamado save/update/persist... dentro de una sesión...
o o se han recuperado de base de datos con un get/load...
guardan los cambios hechos hasta que se hace un commit();

•
•

Problemas?
Dudas?

•

•

Haced el mismo ejercicio que antes, pero cuando recuperéis la sesión llamad
a:
o session.setFlushMode(FlushMode.Manual);

Lo que inserta NO es la transacción es que POR DEFECTO (FlushMode.AUTO),
Hibernate hace un flush cuando haces un commit();

•

Si una entidad está en estado Persistent y hacemos un flush(), los cambios
van a la BD

Entendiendo el estado
Detached

•
•

Probadlo!
o Abrid una sesión, buscad un objeto, cerrad la sesión
o Modificad el objeto
o Abrid la sesión, buscadlo de nuevo...
Ahora tenemos 2 objetos diferentes (en Java) apuntando a la misma fila de la
BD...

•

Problemas con entidades detached e identidad:
o Abrid una sesión, buscad un objeto, cerrad la sesión
o Modificad el objeto
o Abrid la sesión, buscadlo de nuevo...
o Guardad el primer objeto (el que ha sido modificado) con un update
-> ERROR!

•

Si hago un update() ANTES de buscar...
o Todo funciona correctamente, update sincroniza el estado a persistent en
vez de detached.

•

Este caso es poco habitual pero no tan raro cómo parece:
o Típicamente no harás una consulta del elemento directamente y luego un
update().
o Pero sí que es más habitual que ALGO haga una consulta que recupere un
elemento detached (típicamente una asociación con Eager, una
precarga...)

•

Puedo pasar de detached a persistent de cuatro formas:
o session.update() / session.saveOrUpdate()
o session.merge (me crea un objeto "sincronizado")
 Probadlo!
load(1), cerrando sesión
modificando
load(1), merge(), update()/saveOrUpdate()
o session.evict() (sacar de la sesión el objeto que acabo de recuperar)
o session.lock() (igual que el merge si sé con seguridad que no he tocado el
objeto)

•
•
•

•

Usually update() or saveOrUpdate() are used in the following scenario:
o the application loads an object in the first session
o the object is passed up to the UI tier
o some modifications are made to the object
o the object is passed back down to the business logic tier
o the application persists these modifications by calling update() in a
second session

•

saveOrUpdate() does the following:
o if the object is already persistent in this session, do nothing
o if another object associated with the session has the same identifier,
throw an exception
o if the object has no identifier property, save() it
o if the object's identifier has the value assigned to a newly instantiated
object, save() it
o if the object is versioned by a <version> or <timestamp>, and the version
property value is the same value assigned to a newly instantiated object,
save() it
o otherwise update() the object

•

•
•

Merge() is very different:
o if there is a persistent instance with the same identifier currently
associated with the session, copy the state of the given object onto the
persistent instance
o if there is no persistent instance currently associated with the session, try
to load it from the database, or create a new persistent instance
the persistent instance is returned
the given instance does not become associated with the session, it remains
detached

•
•

Otra forma de evitar estos problemas:
o LazyInitializationException
o An instance with...
y que no haya nunca entidades detached...
o es hacer conversaciones, la sesión está abierta siempre.

•

Patrones de transacciones:
o Sesión por operación: ANTI PATRÓN.
o Sesión por request: la más habitual.
o Conversaciones
 Versioning
 Unión de objetos detached

•

Típico flujo de Hibernate con un patrón de request

•

Flujo de Hibernate con un patrón conversación

•
•

En conversación tendremos VARIAS transacciones (en cada carga de pantalla,
vista...), mientras no guardemos nada no hay problema.
Para no guardar nada intermedio:
o Podemos controlar manualmente cuando se hace un flush del contexto
de la Sesión con session.setFlushMode
o Hacemos un flush al final de todo y ya.

•

Problema:
o persist(): it does not guarantee that the identifier value will be assigned
to the persistent instance immediately, the assignment might happen at
flush time. persist() also guarantees that it will not execute an INSERT
statement if it is called outside of transaction boundaries.
o save() does guarantee to return an identifier. If an INSERT has to be
executed to get the identifier ( e.g. "identity" generator, not "sequence"),
this INSERT happens immediately, no matter if you are inside or outside
of a transaction.

•

El problema sólo ocurre en MySQL/SQL Server si uso save...
o es un problema fácilmente mitigable :)

•
•

¿Qué pasa con un flush en medio de una transaccion y luego hago un
rollback?
o setFlushMode(FlushMode.MANUAL)
o session.flush()
o Probadlo!
Y si hago:
o cambio
o flush()
o cambio
o flush()
o rollback()

•

De las dos formas los cambios no son persistidos.

•

Las transacciones deciden si algo se guarda o no.

•

Session.flush() decide QUÉ va a la base de datos.

•

En el segundo caso (varios flush()) se envían varios updates a la BD (varias
sincronizaciones).

•

Conclusiones:
o Con request puro
 Tened cuidado con LazyInitiali... (precargas)
 Cuidado con asociar la misma entidad... (típicamente no hacer
consultas y hacer update al final)
o Con OpenSessionInView (sesión abierta en vista)
 Cuidado con asociar la misma entidad.
o Con Conversaciones
 Sin problemas. Hacer un flush al final y ya.

•
•

•

"By default, the persistence context is flushed (synchronized with the
database) at the end of each transaction."
"As the result of a truly stupid and shortsighted decision by certain nonJBoss, non-Sun and non-Sybase members of the EJB 3.0 expert group, there
is currently no simple, usable and portable way to implement atomic
conversations using EJB 3.0 persistence. However, Hibernate provides this
feature as a vendor extension to the FlushModeTypes defined by the
specification, and it is our expectation that other vendors will soon provide a
similar extension."
Flush mode manual.

Queries
•
•
•
•

HQL
Criteria Hibernate
Criteria JPA
SQL

Criteria Hibernate
•

API clásica de Hibernate (3<)...

•

No está deprecated pero sin desarrollo activo.

•

No es type safe.

•

Trabaja en base a objetos de tipo Criteria.

Criteria Hibernate
•

La sintaxis es:
o session.createCriteria(___.class).list();
o Probad!

Criteria Hibernate
•

El criterio básico de comparación es un objeto de tipo Restrictions:
o Criteria criteria = session.createCriteria(___.class)
o criteria.add(Restrictions.eq("nombre_de_la_propiedad", valor));
o criteria.list();

•

Probadlo!

Criteria Hibernate
•

Muchos tipos de restrictions:
o equal
o notEqual
o gt
o ge
o lt
o le
o between
o like
o in

Criteria Hibernate
•

Intentad hacer una comparación que se traslade a algo como:
o select * from tabla where upper(nombre) like "%algo%"
 ilike (MatchMode.)

•

Method Chaining

•

if (quieroBuscarPorAlgo) then { criteria.add() }...

Criteria Hibernate
•
•

createAlias("solicitudes","solicitud")
Restrictions.eq("solicitud.nombre","LO_QUE_SEA");
o Probadlo! (es el cruce más importante)

•

Alias por defecto de la tabla raíz: {alias}

•

Disjunction

•

addOrder

Criteria Hibernate
Disjunction disjunction = Restrictions.disjunction();
Conjunction conjunction = Restrictions.conjunction();
conjunction.add(2 = 1);
conjunction.add(3 = 2);
disjunction.add(conjunction);
disjunction.add(Restrictions.eqOrIsNull(propertyName, value))
criteria.add(disjunction);
// where (2=1 and 3=2) or (eqOrIsNull)

Criteria Hibernate
•

Comparaciones más complicadas:
o sqlRestrictions()
o Subqueries
o Query by example (criteria.add(Example.create(exampleObject)))
 Probadlo!

Criteria Hibernate
•

¿Qué consultas hacéis?
o Problemas con extensiones del lenguaje (recursividad)
o No tenemos insert/update masivo (en HQL sí)

Criteria JPA 2
•
•

TypeSafe
JPA (necesitas entityManager)

CriteriaBuilder builder = entityManager.getCriteriaBuilder();
CriteriaQuery<Petition> query = builder.createQuery(Petition.class);
Root<Petition> petition = query.from(Petition.class);
query.select(petition);
TypedQuery<Petition> typedQuery = entityManager.createQuery(query);
List<Petition> petitions = typedQuery.getResultList();

•

Ejecutadlo!

Criteria JPA 2
•

Restricciones:
o query.where(builder.equal(petition.get("type"), "elemento"));

Criteria JPA 2
•

Metamodel
o Nos permite hacer restricciones sin cadenas.
o Hay que generarlo: 1, 2 y 3

EntityType<Petition> Petition_ = petition.getModel();
query.where(builder.equal(petition.get(Petition_.type), "elemento"));

•

Recordad:

query.where(builder.equal(petition.get("type"),
"elemento"));

Criteria JPA 2
•

Joins:
o Join<Petition, User> user = petition.join(Petition_.user);

HQL
•

Hibernate Query Language y Java Persistence Query Language (JPQL)
o Extensiones de SQL para trabajar con objetos, sintaxis abreviada.

o Non-type-safe (basado en cadenas)
o Case Insensitive (da igual las mayúsculas: sELEct)

HQL
•
•

El select más sencillo de HQL tiene esta forma:
o "from com.nhpatt.user.User" y recupera todos los elementos de la clase
User (todas las filas de la tabla = select * from User).
Tienen la forma:
[select_clause] from_clause
[where_clause]
[groupby_clause]
[having_clause]
[orderby_clause]

HQL
•
•

Probad un select sin más!
o session.createQuery("from User").list();
o session.createCriteria(User.class).list()
Tienen en cuenta las relaciones de herencia (varias actualizaciones o varias
eliminaciones)

•

Insert, update y delete

•

HQL (y el estándar no) tiene insert

HQL
•

Ejemplo de Update:

String hqlUpdate = "update Petition p set p.type = :newType where p.type
= :oldType";
int updatedEntities = session.createQuery(hqlUpdate)
.setString( "newType", newType )
.setString( "oldType", oldType )
.executeUpdate();

HQL
•

Ejemplo de Select con Joins:

select p
from Petition p
join p.user u
where u.name like '25'

HQL
•
•

Ignora las estrategias de anotaciones por defecto.
Left Join FETCH
o Estrategia Eager!

Native SQL Queries
•
•

En cualquier momento podemos lanzar una consulta SQL directamente con:
o session.createSQLQuery("_consulta_").list();

Probadlo!, qué devuelve?
o ...

Native SQL Queries
•

Podemos especificar el tipo de los resultados, para que les convierta
explícitamente:
o session.createSQLQuery("_consulta_")
.addScalar("ID", Hibernate.LONG)
.addScalar("NAME", Hibernate.STRING)

•

Es útil, pero nos gustaría conversiones automáticas a entidades

Native SQL Queries
•

Hibernate puede convertir el resultado de una query SQL en una entidad
(incluso con asociaciones):
o session.createSQLQuery("_consulta_").addEntity();

•

Asociaciones (eager):

session.createSQLQuery("select * from user u, Petition p WHERE p.userId =
u.id")
.addEntity()
.addJoin();

Native SQL Queries
•

Asociaciones:

•

Es mejor hacer joins.

select {user.*},{role.*} from Usuario user, Role role
where user.role_id = role.id")
.addEntity("user", User.class)
.addEntity("role", Role.class)

Native SQL Queries
•

Hibernate puede transformar resultados de cosas que no son entidades:

sess.createSQLQuery("SELECT NAME, BIRTHDATE FROM CATS")
.setResultTransformer(Transformers.aliasToBean(CatDTO.class))

Native SQL Queries
•

Se pueden utilizar parámetros:

query.setString(0, "");
query.setString("name", "");
"select * from tabla where columna = :name"

No se pueden reutilizar nombres, esto no vale:
"select * from tabla where columna = :name and columna2 = :name"

•

Named Queries

Hibernate - JPA @luce 4

Más contenido relacionado

La actualidad más candente (16)

Similar a Hibernate - JPA @luce 4 (20)

Más de Javier Gamarra (11)

Último (20)

Hibernate - JPA @luce 4