Hibernate - JPA @luce 4

822 views
686 views

Published on

Fourth day of a course about Hibernate, centered in queries and advanced concepts about the Hibernate Session (states, management...)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
822
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Hibernate - JPA @luce 4

  1. 1. Hibernate / JPA @luce4
  2. 2. ¿Qué deberíamos saber? • Relaciones simples @OneToMany y @ManyToOne • Cascades • Tipos de fetching
  3. 3. ¿Qué vamos a ver? • Dudas? • El código está en github.
  4. 4. ¿Qué vamos a ver? • Consultas • Entender la sesión...
  5. 5. Entidades y estados en detalle
  6. 6. Entidades y estados en detalle
  7. 7. Entidades y estados en detalle
  8. 8. 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
  9. 9. Entidades y estados en detalle
  10. 10. Entidades y estados en detalle
  11. 11. Entendiendo el estado Persistent
  12. 12. Entidades y estados en detalle • 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
  13. 13. Entidades y estados en detalle • • • • 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
  14. 14. Entidades y estados en detalle • 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.
  15. 15. Entidades y estados en detalle • • • 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?
  16. 16. Entidades y estados en detalle • • 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();
  17. 17. Entidades y estados en detalle • Si una entidad está en estado Persistent y hacemos un flush(), los cambios van a la BD
  18. 18. Entendiendo el estado Detached
  19. 19. Entidades y estados en detalle • • 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...
  20. 20. Entidades y estados en detalle • 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.
  21. 21. Entidades y estados en detalle • 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...)
  22. 22. Entidades y estados en detalle • 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) • • •
  23. 23. Entidades y estados en detalle • 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
  24. 24. Entidades y estados en detalle • 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
  25. 25. Entidades y estados en detalle
  26. 26. Entidades y estados en detalle • • • 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
  27. 27. Entidades y estados en detalle • • 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.
  28. 28. Patrones
  29. 29. Entidades y estados en detalle • 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
  30. 30. Entidades y estados en detalle • Típico flujo de Hibernate con un patrón de request
  31. 31. Entidades y estados en detalle • Flujo de Hibernate con un patrón conversación
  32. 32. Entidades y estados en detalle • • 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.
  33. 33. Entidades y estados en detalle • 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.
  34. 34. Entidades y estados en detalle • El problema sólo ocurre en MySQL/SQL Server si uso save... o es un problema fácilmente mitigable :)
  35. 35. Entidades y estados en detalle
  36. 36. Entidades y estados en detalle • • ¿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()
  37. 37. Entidades y estados en detalle • 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).
  38. 38. Entidades y estados en detalle • 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.
  39. 39. Entidades y estados en detalle • • • "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.
  40. 40. Queries
  41. 41. Queries • • • • HQL Criteria Hibernate Criteria JPA SQL
  42. 42. Criteria Hibernate
  43. 43. 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.
  44. 44. Criteria Hibernate • La sintaxis es: o session.createCriteria(___.class).list(); o Probad!
  45. 45. 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!
  46. 46. Criteria Hibernate • Muchos tipos de restrictions: o equal o notEqual o gt o ge o lt o le o between o like o in
  47. 47. 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() }...
  48. 48. 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
  49. 49. 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)
  50. 50. Criteria Hibernate • Comparaciones más complicadas: o sqlRestrictions() o Subqueries o Query by example (criteria.add(Example.create(exampleObject)))  Probadlo!
  51. 51. Criteria Hibernate • ¿Qué consultas hacéis? o Problemas con extensiones del lenguaje (recursividad) o No tenemos insert/update masivo (en HQL sí)
  52. 52. Criteria JPA 2
  53. 53. 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!
  54. 54. Criteria JPA 2 • Restricciones: o query.where(builder.equal(petition.get("type"), "elemento"));
  55. 55. 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"));
  56. 56. Criteria JPA 2 • Joins: o Join<Petition, User> user = petition.join(Petition_.user);
  57. 57. HQL
  58. 58. 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)
  59. 59. 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]
  60. 60. 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
  61. 61. 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();
  62. 62. HQL • Ejemplo de Select con Joins: select p from Petition p join p.user u where u.name like '25'
  63. 63. HQL • • Ignora las estrategias de anotaciones por defecto. Left Join FETCH o Estrategia Eager!
  64. 64. Native SQL Queries
  65. 65. Native SQL Queries • • En cualquier momento podemos lanzar una consulta SQL directamente con: o session.createSQLQuery("_consulta_").list(); Probadlo!, qué devuelve? o ...
  66. 66. 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
  67. 67. 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();
  68. 68. 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)
  69. 69. 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))
  70. 70. 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
  71. 71. ¿Dudas?
  72. 72. Hibernate / JPA @luce4

×