Taller de Sistemas de Información 2. Java Persistence API

Texto completo

(1)Taller de Sistemas de Información 2 Java Persistence API.

(2) El concepto de persistencia • En Java manipulamos objetos, los cuales son instancias de clases • Los objetos tienen referencias a otros objetos o a colecciones de los mismos • En forma recursiva pueden referenciarse a si mismos • Los objetos encapsulan datos y comportamiento • El problema es que este estado es accesible solo mientras la JVM esta ejecutando • Si la JVM se detiene o si el garbage collector destruye un objeto, este estado desaparece • Algunos objetos necesitan que sus datos perduren la vida de la JVM.

(3) El concepto de persistencia • Un objeto que puede almacenar su estado en un medio permanente y durable, se dice que es un objeto persistente • En las aplicaciones empresariales, el estado persistente suele almacenarse en bases de datos relacionales • Existen diversos mecanismos para lograr este objetivo • Utilizar mecanismos manuales basados en JDBC • Realizar un mapeo automático entre instancias de clases y tuplas de una base de datos, a través de un ORM. • JPA es la especificación de una solución de ORM para la plataforma Java EE.

(4) Entidades • Cuando decimos que un objeto se mapea en una tabla de una base de datos relacional, se utiliza el termino ENTIDAD en lugar de OBJETO • Los objetos son instancias que solo viven en memoria • Las entidades son objetos que viven corto tiempo en memoria, pero son persistentes en la base de datos.

(5) Entidades • Tienen la habilidad de ser mapeadas a la base de datos • Pueden ser concretas o abstractas • Soportan herencia y relaciones • Una vez que una entidad es mapeada a la base de datos, puede ser gestionada por JPA • Podemos persistir, eliminar y consultar una entidad de la base de datos.

(6) Entidades • En el mundo JPA, es un POJO • Tienen metadatos • Manejan estado, el cual puede ser accedido por getters y modificado por setters • El estado de la entidad esta representado por los valores de los atributos de la misma.

(7) OBJETO.

(8) ENTIDAD.

(9) Entidades • Están anotadas con: • @javax.persistence.Entity. • Debemos marcar un atributo como clave primaria, usando la anotación: • @javax.persistence.Id. • Debe tener un constructor por defecto (publico o protected) • Debe ser una clase top-level (no puede interfaz o enumerado).

(10) Entidades • La clase no puede estar marcada con “final” • Ningún método o atributo de la clase puede estar marcado con “final” • Si la entidad debe ser pasada como parámetro a través de una interfaz remota, entonces debe implementar la interfaz java.io.Serializable.

(11) Object-Relational Mapping • A través del uso de metadatos (XML o anotaciones), JPA puede mapear las entidades en la base de datos • Un proveedor de persistencia (implementación de JPA) es el encargado de usar estos metadatos para sincronizar el estado entre los atributos de la entidad y la tabla.

(12)

(13)

(14) Proveedor de persistencia.

(15) Manipulando entidades • Una vez que tenemos las entidades mapeadas, podemos utilizar JPA para acceder a las entidades • Podemos consultar entidades y sus relaciones, SIN CONOCER la estructura de la base subyacente • El elemento central de JPA que permite realizar esto, es el API: • javax.persistence.EntityManager.

(16) Manipulando entidades • El rol del EntityManager es • • • •. Gestionar entidades Leer y escribir de una base de datos Permitir operaciones CRUD simples Permitir consultar complejas usando JPQL. • Es una interfaz cuya implementación la brinda un proveedor de persistencia.

(17) Manipulando entidades • Por ejemplo, podemos usar el EntityManager de esta forma:.

(18) Manipulando entidades.

(19) Extendemos la entidad.

(20)

(21)

(22)

(23)

(24)

(25)

(26) Persistence Unit • Algo que nos falta en los códigos anteriores es: • • • • •. A que base de datos nos conectamos? Como nos conectamos? Cual es servidor, puerto y nombre de la base? Con que usuario nos conectamos? Que driver JDBC vamos a utilizar?. • Esta información se encuentra en un elemento denominado Persistence Unit.

(27) Persistence Unit • Cuando se crea el EntityManagerFactory, el nombre de la unidad de persistencia se le pasa como parámetro • PERSISTENCE_CONTEXT_NAME. • La información a utilizar para establecer la conexión, se coloca en el archivo persistence.xml, en el classpath del modulo, dentro del directorio META-INF.

(28)

(29)

(30)

(31)

(32) Ciclo de vida de una entidad.

(33) Bean Validation • Además de la validación manual (a través de un Validator), es posible utilizar Bean Validation automáticamente en una entidad JPA • Las constraints pueden ser aplicadas en clases de entidad, clases embeddable y mapped superclases • La validación ocurre automáticamente siempre luego de los eventos • PrePersist • PreUpdate • PreRemove.

(34)

(35) ORM • Para establecer el vinculo entre las entidades en el mundo Java y los elementos a nivel relacional, debemos definir las anotaciones de ORM para la entidad • JPA utiliza configuración por excepción • A menos que especifiquemos lo contrario, se asumen valores por defecto • En ciertas situaciones, esto no nos sirve (ej. acceder a un esquema legado).

(36) @Table • Por defecto el nombre de la tabla y la entidad coinciden • Para configurar esto, debemos usar la anotación @javax.persistence.Table • El elemento mas básico que podemos cambiar es el nombre de la tabla • @Table(name = "t_book"). • Podemos especificar el schema y el catalog de la tabla.

(37)

(38) @SecondaryTable • Permite colocar los datos de una entidad, en una tabla y N tablas secundarias subordinadas • Podemos especificar una @SecondaryTable o un conjunto de tablas, usando @SecondaryTables • Para cada atributo, usando @Column, podemos especificar a que tabla pertenece.

(39)

(40)

(41) @SecondaryTable • Debemos tener cuidado con este tipo de tablas y la performance • Cuando queremos acceder a los atributos de una entidad, vamos a tener que realizar un join entre las tablas involucradas • Pueden ser una buena alternativa cuando tenemos atributos costosos (BLOBs) que queremos aislar en tablas especificas.

(42) Primary Keys • Identifican unívocamente una tupla en una tabla en la base de datos • Puede ser una columna o un conjunto de columnas • JPA requiere que las entidades tengan un identificador mapeado a una clave primaria • Una vez actualizado (en la base), el valor de una clave primaria no puede ser actualizado.

(43) @Id / @GeneratedValue • @Id es utilizado para denotar un atributo simple que se mapea a la clave primaria • Puede ser del siguiente tipo: • • • •. Primitivo: byte, int, short, long, char Wrapper: Byte, Integer, Short, Long, Character Arrays de primitivos/wrappers: int[], Integer[] Strings, numeros y fechas: String, BigInteger, Date.

(44) @Id / @GeneratedValue • El valor de la clave primaria puede ser asignado en forma manual o ser generado automáticamente • Para esto usamos la anotación @GeneratedValue, que puede tomar cuatro valores posibles • SEQUENCE , IDENTITY, TABLE, AUTO • El valor por defecto es AUTO.

(45)

(46) Campos Identity • La base debe soportar columnas de tipo autogeneradas, como SQL Server y MySQL • Debemos hacer….

(47) Tabla • Podemos generar los valores de clave primaria a través de una tabla e la propia base de datos • Esta tabla contendrá una fila por cada entidad que necesite generar valores de clave primaria • Podemos usar los valores por defecto o utilizar una tabla ya creada.

(48) Tabla • Para mapear a una tabla existente, usamos un TableGenerator.

(49) Tabla • La tabla generada en este caso se mapea a la siguiente estructura.

(50) Estrategia por defecto • Cuando especificamos que la estrategia es AUTO, estamos indicando que el proveedor de persistencia puede seleccionar la estrategia que crea conveniente • Generalmente la selección es TABLE, ya que es el mecanismo garantizado para cualquier manejador de base de datos • En el caso de utilizar Hibernate como proveedor de persistencia, el nombre de la tabla por defecto, es “hibernate_sequences”.

(51) Primary Keys compuestas • Cuando se mapean las entidades, es una buena practica: • Usar una única columna como clave • Que esta columna sea de un tipo integral (INTEGER, LONG, etc.). • A veces esto no es posible • Si tengo que adherir la clave a ciertas reglas de negocio • Si tengo que mapear un esquema legado. • Tenemos dos posibilidades, @EmbeddedId o @IdClass..

(52) @Embedded • La anotación @Embedded representa objetos que serán embebidos dentro de otros objetos • Un objeto embebido no tiene identidad (no tiene PK por si mismo) • Sus atributos terminaran formando parte de las columnas de la tabla que contiene el objeto embebido.

(53) @Embedded • Un objeto de este tipo debe: • • • •. Tener un constructor sin parámetros Debe tener getters y setters para los atributos allí presentes Debe definir el método equals y el método hashCode La clase no tiene una identificación por si misma, esto es, no tiene atributos marcados con @Id.

(54) @Embedded.

(55) @EmbeddedId • Esta anotación se utiliza cuando representamos los campos de una clave compuesta a través de un @Embedded • En este caso, no necesitamos indicar la clave primaria con @Id.

(56) @EmbeddedId • En este caso, la clave primaria no es un atributo simple, sino que esta representada por una instancia del objeto embebido • Para utilizarla, debemos hacer:.

(57) @IdClass • Es parecido al mecanismo anterior, pero los atributos que componen la clave primaria, deben especificarse en la clase utilizando @Id (por separado).

(58) @IdClass • Luego, en la clase indicamos cual es la clase que representa los valores de clave primaria.

(59) Atributos • Componen el estado de la entidad • Entre otros, podemos mapear los siguientes tipos: • • • • • •. Primitivos y sus correspondientes wrappers Arrays de bytes y chars Strings, tipos numéricos y tipos temporales Tipos enumerados Tipos que implementen Serializable Colecciones de tipos básicos y embeddables.

(60) Atributos • Una entidad también puede tener atributos • De tipo entidad • Colecciones de entidades • Clases embebidas. • Estos tipos de atributos, requieren el uso de relaciones entre entidades • Como con los nombres de tablas, se utiliza configuración por excepción.

(61) @Basic • Es la anotación mas simple para mapear un campo a la base de datos • Permite hace un override a la forma en como se levantan los datos de la base.

(62) @Basic • optional • Permite indicar si el atributo puede o no ser nulo • No aplica para tipos de datos primitivos. • fetch • • • •. Puede tomar dos valores: LAZY o EAGER Le indica al provider cuando debe cargar el dato en cuestión EAGER: Cuando se carga la entidad LAZY: Cuando se accede al atributo.

(63)

(64) @Column.

(65)

(66) @Column • Un aspecto importante se da cuando tenemos un atributo con • Una validación B.V. del tipo @NotNull • Un mapeo @Column con el atributo nullable en false. • La primera aplica en el espacio de Java • La segunda aplica en el espacio de la base de datos.

(67) @Temporal • Los tipos de datos Date (java.sql y java.util) puede ser llevados a la base a diferentes representaciones • Para controlar esto, usamos la anotación @Temporal, que puede tomar tres valores • DATE: Solo se almacena la fecha • TIME: Solo se almacena la hora • TIMESTAMP: Se almacena fecha y hora completa.

(68)

(69) @Transient • En JPA, cuando anotamos la clase con @Entity, esto hace que todos sus campos formen parte del estado persistente • Si no queremos persistir un atributo de una entidad, podemos: • Colocarle la anotación @Transient • Colocarle el modificador de acceso transient al atributo.

(70)

(71) @Enumerated • Los valores de un enumerado son constantes, que tienen implícito un ordinal, el cual depende del orden en el que fueron declarados • En la base de datos, podemos almacenas la constante (como string) o el ordinal del enumerado.

(72) @Enumerated • @Enumerated acepta dos posibles valores • EnumType.STRING para indicar que se quiere guardar el nombre de la constante del valor del enumerado • EnumType.ORDINAL para indicar que se quiere guardar el ordinal del valor del enumerado • ORDINAL es el valor por defecto.

(73)

(74) Embeddables • Tienen 2 partes • La clase que se embebe • La clase que embebe a la primera. • En el primer caso se usa la anotación @Embeddable para indicar que es un objeto que puede ser embebido dentro de otro • En el segundo caso, se usa la anotación @Embedded para indicar que estamos colocando un objeto embebible allí.

(75)

(76)

(77)

(78) Relaciones entre objetos • Representa un vinculo entre dos entidades • Tienen dirección • Puede ser unidireccionales o bidireccionales.

(79) Relaciones entre objetos • Tienen cardinalidad • Esto refiere a la cantidad de participantes en cada extremo de la relación.

(80) Relaciones en la base • Pueden ser establecidas con columnas de join (foreign keys).

(81) Relaciones en la base • O pueden ser establecidas por tablas de mapeo.

(82) Relaciones entre entidades.

(83) Relaciones entre entidades • Customer y Address tienen una relación unidireccional.

(84) Relaciones entre entidades • Customer y Address tienen una relación bidireccional.

(85) CUIDADO • Lo anterior, NO ES exactamente igual a esto.

(86)

(87) @OneToOne • En estos casos, se tiene una referencia a un elemento.

(88)

(89)

(90)

(91)

(92) @OneToOne.

(93) @JoinColumn • Es similar a @Column, solo que es utilizada para customizar la columna de foreign key • Siempre debe utilizarse en el lado “dueño” de la relación (el que no contiene mappedBy) • En el caso anterior, no tenemos lado mappedBy, solamente uno, debido a que es unidireccional.

(94)

(95) @OneToMany unidireccional • En este caso, el objeto origen mantiene una colección de objetos destino.

(96)

(97)

(98) @OneToMany unidireccional • Este tipo de relaciones en JPA, generan una tabla intermedia de mapeo entre ambas entidades.

(99) @JoinTable • Podemos usar esta anotación para customizar la tabla de mapeo entre ambas entidades.

(100)

(101) @JoinTable • La tabla obtenida, en este caso cambia a lo siguiente:.

(102) @OneToMany unidireccional • Para relaciones de este estilo, la acción por defecto es usar una tabla de mapeo • Sin embargo, es posible modificar esto para utilizar una columna de join en la tabla subordinada • Basta indicar en la entidad padre, que vamos a utilizar una @JoinColumn en lugar de @JoinTable.

(103)

(104) @OneToMany unidireccional • En este caso, la tabla de mapeo queda de la siguiente forma:.

(105) @OneToMany bidireccional • Para transformar esta relación en bidireccional, en realidad debemos hacer que la línea de la orden referencia a la orden • Para esto, agregamos una referencia a la orden y utilizamos la anotación @ManyToOne • Es importante en este caso, que la anotación tenga el atributo “mappedBy” para indicar que es la inversa de la anterior.

(106)

(107) @ManyToMany bidireccional.

(108) @ManyToMany bidireccional • Las tablas obtenidas en estos casos son las siguientes:.

(109) Fetching • Todas las anotaciones definen un mecanismo de fetching (recuperación de datos) • Los objetos asociados pueden ser cargados: • Inmediatamente: FetchType.EAGER • Cuando se requieran: FetchType.LAZY.

(110) Fetching • Por ejemplo, en esta situación:. • Ni bien levantemos el primer objeto (por ejemplo, buscando por ID), vamos a levantar TODO lo relacionado • El impacto en performance es enorme.

(111) Fetching • En esta otra situación:. • Solo si hacemos esto: • class1.getClass2().getClass3().getClass4() • Entonces en ese momento se van a cargar los datos de las entidades relacionadas.

(112) Fetching.

(113)

(114) Herencia • Es un concepto que a nivel relacional no tiene contraparte como en el caso de las relaciones • El problema que tenemos es como mapear un modelo jerárquico (Java) en un modelo plano (relacional) • JPA provee tres estrategias para resolver este problema (cada una con ventajas y desventajas).

(115) Herencia • single-table-per-class-hierarchy • Todos los atributos, de todas las entidades, se colocan en una única tabla • Es la estrategia por defecto. • joined-subclass • Cada entidad en la jerarquía, concreta o abstracta, es mapeada en su propia tabla. • table-per-concrete-class • Cada entidad concreta de la jerarquía, se mapea en una tabla • Es opcional en JPA 2.x (CUIDADO).

(116)

(117) Single-Table-per-Class Hierarchy • La anotación usada es @Inheritance • Pero podemos omitir completamente el uso de anotaciones porque este es el enfoque por defecto.

(118)

(119)

(120)

(121) Single-Table-per-Class Hierarchy • El problema con este tipo de tablas, es que generan tablas con muchos huecos • Pero son muy buenas, porque no tenemos que hacer JOINs para levantar los datos.

(122) Single-Table-per-Class Hierarchy • Como los datos de las diferentes entidades están juntos, necesitamos una forma de discriminarlos • Por esto, se agrega una columna nueva, el discriminador (DTYPE) • Por defecto es de tipo String, mapeándose a un Varchar en la base • Podemos customizar esta con @DiscriminatorColumn.

(123) @DiscriminatorColumn.

(124)

(125)

(126) @DiscriminatorColumn • En este caso, los datos almacenados cambian a lo siguiente:.

(127) Joined-Subclass.

(128) Joined-Subclass.

(129) Joined-Subclass • Aun podemos usar el discriminador en las clases, para customizar e indicar el tipo de entidad en la tabla de la clase raíz • Este enfoque es el mas intuitivo, y el mas similar a una jerarquía Java • El problema que tiene, es la cantidad de JOINs requeridos para recuperar los datos de una clase concreta.

(130) Table-per-Concrete-Class.


(132) Table-per-Concrete-Class • En este enfoque, las tablas en las hojas, replican los atributos en clases concretas mas arriba en la jerarquía • En JPA, por defecto se les coloca el mismo nombre • Pero puede suceder que un esquema legado utilice nombres diferentes • Podemos hacer entonces un override de los atributos.

(133)

(134)


(136) Tipos de entidades en jerarquía • Entidades abstractas • No siempre las entidades de las que se hereda tienen porque ser concretas • En este caso, el mapeo es como el de una entidad, la única diferencia es que la clase no se puede instanciar. • Clases transient (no-entidades) • No generan información de mapeo, por lo tanto sus atributos no forman parte del estado persistente.

(137)

(138)

(139)

(140) Gestionando los objetos • El EntityManager es la pieza central de JPA • Permite, dentro de un contexto de persistencia • • • •. Crear y remover entidades Localizar entidades por clave primaria Permite lockear el acceso a entidades (en forma pesimista u optimista) Permite crear y ejecutar queries en JPQL o usando el API de Criteria.

(141) EntityManager • Mientras una entidad no entre en contacto con una instancia de un EntityManager, se dice que NO esta siendo administrada • En cuanto entra en contacto (creación, query, modificación, etc.) ahí decimos que pasa al estado MANAGED • En este estado, el EntityManager se encargara de sincronizar automáticamente el estado con la base de datos.

(142) Obteniendo un EntityManager • Tenemos dos tipos de EntityManager • Application Managed EntityManager • Container Managed EntityManager. • El primer caso se da cuando usamos el EntityManager fuera de un servidor de aplicaciones • En el segundo, estamos dentro de un servidor, como WidlFly.

(143)

(144)

(145)

(146)

(147) Persistence Context • Es un conjunto de entidades administradas (managed), en un momento dado y para una transacción de un usuario dada • Solo una instancia de una entidad, con la misma identidad persistente (PK) puede existir en un persistence context • Solo las entidades contenidas en un persistence context son manejadas por el EntityManager.

(148) Persistence Context • El EntityManager actualiza o consulta el contexto de persistencia cuando un método del API de EntityManager es invocado • Por ejemplo: • Cuando se invoca el método “persist”, la entidad pasada como parámetro se agrega al contexto de persistencia, si no existe en el mismo • Cuando se busca una entidad por ID, primero se verifica si no esta cargada en el contexto de persistencia.

(149) Persistence Context • Por los motivos anteriores, el contexto de persistencia se denomina también “cache de primer nivel” • Por defecto, los objetos viven en el contexto de persistencia, SOLO MIENTRAS DURE LA TRANSACCION ACTUAL • Por ejemplo, si tenemos dos usuarios ejecutando en dos transacciones diferentes….

(150)

(151) Persistence Unit • Es el archivo que permite configurar el contexto de persistencia • Viene dado por el archivo persistence.xml • Se encuentra en el META-INF dentro del classpath de la aplicación • Permite establecer diferentes tipos de parámetros para configurar el contexto de persistencia creado • Se pueden utilizar propiedades estándar y/o propiedades del proveedor de persistencia (por ejemplo Hibernate) • Por ejemplo….

(152)

(153) Persistence Unit.

(154)

(155)

(156) Ejemplo… • Las tablas asociadas al ejemplo anterior quedan de la siguiente forma:. • Asumamos que em es una instancia de EntityManager y tx una instancia de EntityManagerTransaction.

(157) Persistiendo una entidad • Si los datos no existen en la base, serán insertados • En caso contrario, se propaga una EntityExistsException.

(158) Buscando por ID • Dado el ID, usamos el método “find”. • Si la entidad existe, es devuelta • Si no existe, se retorna null.

(159) Buscando por ID • Otra forma alternativa, es usando el método getReference, que levanta los datos de la entidad en forma LAZY.

(160) Buscando por ID • En el caso de getReference, si la entidad no existe, se genera la excepción EntityNotFoundException • Los datos de la entidad se recuperan en forma LAZY, por lo que debe hacerse esto DENTRO del contexto de persistencia • Si la entidad se vuelve detached, ya no podemos recuperar los datos, generando una LazyInitializationException.

(161) Borrando una entidad • Utilizamos el método “remove” • Al borrar una entidad, esta: • • • •. Se elimina de la base de datos Se desvincula del persistence context Pasa a estado detached No puede volver a ser sincronizada. • Sin embargo, el objeto aun es accesible desde Java (es un POJO tradicional).

(162)

(163) Sincronización con la base • El EntityManager tiene un cache de primer nivel, esperando a que la transacción se commitee, o que los datos sean “flusheados” a la base • Cuando realizamos múltiples operaciones con el contexto de persistencia (persistir dos entidades por ejemplo) las sentencias se hacen permanentes cuando se commitean los cambios.

(164) Flushing • El método “flush” puede hacer que los datos sean enviados a la base, pero aun no se commitee la transacción • El problema que podemos tener al flushear manualmente, es que podemos ejecutar sentencias que pueden violar una restricción de integridad • Por ejemplo….

(165) Refresh • Es usado para sincronizar datos, pero en la dirección opuesta al flush • Esta operación sobre escribe el estado persistence de la entidad en el cache de primer nivel • Es útil para cuando queremos deshacer cambios que hicimos en memoria.

(166) Refresh.

(167) Contains • El método contains() retorna un booleano (true o false), indicando si en el contexto de persistencia actual, una entidad esta siendo administrada.

(168) Contains.

(169) Clear y Detach • El método clear() limpia el contexto de persistencia • Todas las entidades managed pasan automáticamente a estado “detached” • El método detach() recibe una entidad y la desconecta del contexto de persistencia • Cualquier cambio que se haga sobre la misma no será sincronizado contra la base de datos.

(170) Clear y Detach.

(171) Merging • Para asociar una entidad que esta desconectada de un contexto de persistencia, debemos re - attachearla (mergearla) • Es una situación común cuando: • Una entidad es devuelta por un componente de negocio a presentación • Se le hacen cambios en presentación • Es enviada al componente de negocio para ser actualizada en la base.

(172) Merging.

(173) Actualización de una entidad • Tenemos dos formas de hacerlo • La anterior, en la cual una entidad detached (con cambios en su estado), es mergeada al persistence context actual • Pero si la entidad ya esta managed, los cambios se efectuaran automáticamente sin necesidad de mergear explícitamente.

(174) Cascading • Existen situaciones en las cuales las operaciones aplicadas sobre una entidad, deben ser propagadas a las entidades relacionadas • Esto es lo que se denomina “Cascade de eventos” • Por ejemplo, si Customer y Address estan vinculados, podemos hacer esto:.

(175) Cascading • En este caso, estamos explícitamente guardando ambos elementos.

(176) Cascading • Si usamos Cascade al persistir, obtenemos.

(177)

(178) Cascading – Eventos.

(179) JPQL • Es un lenguaje de consulta usado para definir búsquedas contra las entidades, independientemente del motor de base de datos utilizado • Es muy similar al SQL • En vez de tablas, usamos clases • En vez de columnas, usamos atributos • En vez de joins por FKs, usamos navegación.

(180) JPQL • El ejemplo mas simple de consulta JPQL es:. SELECT b FROM Book b • Book representa una entidad • b representa un alias utilizado en la consulta (en este caso, es similar a * en SQL).

(181) JPQL – Forma general.

(182) Select • Permite seleccionar los resultados de la consulta • Permite devolver lo siguiente • • • • •. Una entidad Un atributo de una entidad Una “constructor expression” (un New) Una función de agregación Una expresión de navegación (usando el “.”).

(183) Select • La forma general es:. • Por ejemplo, si Customer es una entidad, a la cual se le da el alias “c”, entonces estos son unos ejemplos simples de selección:.

(184)

(185) Select • Desde JPA 2.0, se soporta en la selección el operador CASE-WHENTHEN-ELSE.

(186) Select • Si Customer tiene una relación (a 1) con Address, entonces la siguiente consulta retorna una lista de direcciones.

(187) Select • Si Address tiene una relación con Country, el cual tiene un código (code), entonces podemos usar la navegación con “.” para recuperar ese valor.

(188) Select • Podemos usar un constructor en el select, creando nuevas instancias de los elementos seleccionados.

(189) Select • Para remover duplicados, podemos usar el operador DISTINCT.

(190) Select • Podemos usar funciones de agregación sobre los elementos del Select • Tenemos las operaciones de agregación • AVG, COUNT, MAX, MIN, SUM. • Los resultados pueden ser agrupados usando GROUP BY y ser filtrados usando HAVING • Tenemos también funciones escalares que podemos usar en el SELECT, en el WHERE y en el HAVING.

(191) Select • Sobre valores numéricos: • ABS, SQRT, MOD, SIZE, INDEX. • Sobre valores strings • CONCAT, SUBSTRING, TRIM, LOWER, UPPER, LENGTH, LOCATE. • Sobre valores fecha • CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP.

(192) From • Define las entidades sobre las que vamos a buscar, utilizando variables de identificación • Una variable de identificación es un alias • Permite utilizar dicho alias en los demás elementos de la consulta (Select, Where).

(193) Where • Es una expresión booleana usada para restringir el resultado de un Select, un Update o un Delete.

(194) Where • Soporta los siguientes operadores • =, >, >=, <, <=, <>. • [NOT] BETWEEN, [NOT] LIKE, [NOT] IN • IS [NOT] NULL, IS [NOT] EMPTY • [NOT] MEMBER [OF] • LIKE.

(195)

(196) Parámetros • JPQL soporta parámetros posicionales • Se especifican con un “?”, seguido de la posición (1, 2, …) • Cuando se ejecuta la query, los parámetros deben ser reemplazados.

(197) Parámetros • También soporta parámetros nombrados • Se especifican con un “:” seguido de un nombre lógico • Como en el caso anterior, al ejecutar se debe dar valor a los parámetros.

(198) Subqueries • Es una query que puede ser embebida en un WHERE o en un HAVING • La evaluación ocurre como parte de la evaluación de la consulta padre.

(199) Order by • Como en el caso de SQL, permite ordenar los valores devueltos.

(200) Group by / Having.

(201)