Hibernate - JPA @luce 4

Hibernate / JPA @luce4

¿Qué deberíamos saber?

• Relaciones simples @OneToMany y @ManyToOne

• Cascades

• Tipos de fetching

¿Qué vamos a ver?

• Dudas?

• El código está en github.

https://github.com/nhpatt/hibernate/commits/master

¿Qué vamos a ver?

• Consultas

• Entender la sesión...

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 commito 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 Pepeo cambio a Lolao rollback() -> en BD sigue Pepeo mi modelo Java sigue poniendo Lola


• Para ver el estado Persistent tras un get/loado Recuperad un objeto de BDo Cambiad un valor del objetoo 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óno Modificad el objetoo 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óno Modificad el objetoo 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 sessiono the object is passed up to the UI tiero some modifications are made to the objecto the object is passed back down to the business logic tiero 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 nothingo if another object associated with the session has the same identifier,

throw an exceptiono if the object has no identifier property, save() ito if the object's identifier has the value assigned to a newly instantiated

object, save() ito 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 LazyInitializationExceptiono An instance with...

• y que no haya nunca entidades detached...o es hacer conversaciones, la sesión está abierta siempre.

Patrones


• 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.setFlushModeo 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 cambioo flush()o cambioo 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 non-JBoss, 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

Queries

• HQL• Criteria Hibernate• Criteria JPA• SQL

Criteria Hibernate

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 equalo notEqualo gto geo lto leo betweeno likeo 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

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

• Metamodelo 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"));

http://sourceforge.net/projects/hibernate/files/hibernate-jpamodelgen/

http://relation.to/Bloggers/HibernateStaticMetamodelGeneratorAnnotationProcessor

http://docs.jboss.org/hibernate/stable/jpamodelgen/reference/en-US/html_single/

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)

http://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html_single/#d5e2575

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 FETCHo Estrategia Eager!

Native SQL Queries

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:select {user.*},{role.*} from Usuario user, Role role

where user.role_id = role.id")

.addEntity("user", User.class)

.addEntity("role", Role.class)

• Es mejor hacer joins.

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

http://docs.jboss.org/hibernate/orm/4.2/devguide/en-US/html_single/#querysql-namedqueries

¿Dudas?

Hibernate / JPA @luce4

Hibernate - JPA @luce 4

Technology

Transcript of Hibernate - JPA @luce 4