Gu铆a de Spring Data JPA

    驴Qu茅 es Spring Data JPA?

    Spring Data JPA es parte de la familia Spring Data .

    Hablemos sobre qu茅 es Spring Data JPA y algunas de las caracter铆sticas que cubriremos en este art铆culo. En primer lugar, este marco se basa en el popular y poderoso marco de Spring y se considera uno de los proyectos centrales del conjunto de herramientas de Spring.

    Spring Data JPA tambi茅n se basa en y mejora JPA, que significa “API de persistencia de Java”. La mayor铆a de las aplicaciones est谩n respaldadas por alg煤n tipo de almac茅n de datos. A medida que crece la complejidad de su aplicaci贸n y el conjunto de caracter铆sticas, ver谩 que su nivel de acceso a datos y su c贸digo de nivel de persistencia tambi茅n crecer谩n.

    Uno de los objetivos principales de Spring Data JPA es reducir su c贸digo y simplificar su capa de acceso a datos, al mismo tiempo que mantiene un conjunto de funcionalidades rico y completo. Para que esto sea posible, Spring Data JPA le permite crear interfaces inteligentes estereotipadas de Spring Repository.

    Estos repositorios son interfaces Java que le permiten a usted, como desarrollador, definir un contrato de acceso a datos. El marco Spring Data JPA puede inspeccionar ese contrato y construir autom谩ticamente la implementaci贸n de la interfaz debajo de las cubiertas para usted.

    Para que Spring Data JPA genere de manera inteligente una implementaci贸n de la interfaz de su Repositorio, se necesita una consulta DSL.

    DSL es un acr贸nimo de Domain Specific Language. El lenguaje espec铆fico de dominio de consulta le permite crear m茅todos de interfaz Java que utilizan ciertas palabras clave junto con atributos de entidad JPA para realizar el trabajo necesario para implementar correctamente sus consultas sin tener que proporcionar mucho en la forma de codificaci贸n real. Tambi茅n cubriremos casi todo lo que necesita saber sobre las especificaciones de Query DSL.

    Y por 煤ltimo, Spring Data JPA proporciona algunos extras interesantes que a menudo se ven y se utilizan en las capas de acceso a datos en niveles persistentes. Las funciones como la auditor铆a, la paginaci贸n y el manejo de consultas SQL nativas se pueden utilizar con el marco Spring Data JPA. Si por alguna raz贸n, Spring Data JPA no puede proporcionar una soluci贸n para una de sus necesidades de la capa de acceso a datos, puede salirse del camino f谩cilmente y permitirle codificar o trabajar en paralelo, o fuera del marco por completo, sin pisar los dedos de los pies.

    Antes de empezar

    Antes de entrar en m谩s detalles con Spring Data JPA, quiero hablar sobre lo que este art铆culo no cubrir谩. Primero, no profundizaremos con JPA y ORM, o conceptos de mapeo relacional de objetos.

    De hecho, estos temas son lo suficientemente amplios como para justificar sus propios cursos y tutoriales. Asimismo, no vamos a ir a fondo en las relaciones, como one-to-many, many-to-many, many-to-one, y as铆 sucesivamente. Esos temas se tratan bien en los otros cursos y tutoriales de JPA. Tampoco entraremos en estructuras SQL, JDBC, JPAQL y NoSQL.

    Utilizaremos JPAQL en este art铆culo cuando hablemos de Spring Data JPA Query DSL, por lo que tener un conocimiento b谩sico de SQL y JPAQL definitivamente ser谩 beneficioso. Y por 煤ltimo, no cubriremos conceptos de Core Spring como Dependency Injection, el contexto y contenedor de Spring y la configuraci贸n b谩sica de Spring.

    Tambi茅n cubriremos algunos ejemplos de c贸digo para ganar experiencia y comprensi贸n de Spring Data JPA a lo largo de este art铆culo.

    Necesitar谩 herramientas como Java, Maven y un IDE (IntelliJ, Eclipse o NetBeans) para configurar en su m谩quina de desarrollo para aprovechar al m谩ximo este art铆culo.

    Elecci贸n de una capa de acceso a datos de Java

    Siempre que est茅 creando o trabajando en una capa de acceso a datos o un nivel de persistencia, tiene una variedad de opciones que puede usar. Quiero tomarme un minuto para hablar sobre estas opciones para ayudarlo a ver d贸nde puede encajar Spring Data JPA arquitect贸nicamente. Tambi茅n debe darse cuenta de que ning煤n marco o API normalmente funciona para todo. Y las mejores capas de acceso a datos suelen ser un h铆brido de marcos.

    Si est谩 trabajando con una base de datos realmente simple con quiz谩s solo unas pocas tablas o si tiene muchas necesidades de SQL nativo, entonces algunos marcos de la capa de acceso a datos pueden ser una exageraci贸n. Usar JDBC directo o Spring JDBC con Native SQL puede ser su mejor y m谩s simple opci贸n. A veces, sus informes deben dictar una determinada capa de acceso a datos, y JDBC o Native SQL pueden funcionar mejor para eso.

    Si tiene una aplicaci贸n que necesita realizar muchas inserciones, actualizaciones o eliminaciones de SQL, querr谩 obtener un marco que se especialice en esa funcionalidad en particular. JPA no es un gran candidato para grandes cantidades de escrituras en su almac茅n de datos. La raz贸n por la que JPA u ORM en general luchan con escrituras grandes es que la naturaleza del marco requiere que cree el gr谩fico de su objeto en la memoria, luego lo actualice con los valores modificados y luego lo conserve en su almacenamiento de datos.

    Si est谩 trabajando con 谩rboles de gr谩ficos realmente grandes, esto puede ser bastante costoso en t茅rminos de tiempo y terminar creando grandes huellas de memoria en su servidor. En su lugar, probablemente deber铆a buscar un marco que maneje el procesamiento por lotes espec铆ficamente. Por ejemplo, un marco como Spring Batch o Hadoop. Java EE 7 tambi茅n contiene un componente de escritura por lotes como parte de su funcionalidad principal ahora. Aseg煤rese de tener todo en cuenta cuando cree su arquitectura inicial y apile para su aplicaci贸n Java.

    Instalaci贸n de Spring Data JPA

    Vamos a instalar y configurar Spring Data JPA. Primero, necesitaremos agregar la dependencia de Spring Data JPA en nuestra ruta de clases de la aplicaci贸n.

    Dado que estamos usando Maven para manejar nuestras dependencias, podemos agregar este bloque de dependencias en nuestro pom.xmlarchivo.

    A continuaci贸n, deber谩 indicarle a Spring que configure y cargue los repositorios JPA. Aqu铆 es donde ocurre la mayor parte de la magia de Spring Data JPA. Este paso en la instalaci贸n de Spring Data JPA es donde puede implementar la interfaz de su repositorio debajo de las cubiertas cuando se inicia la aplicaci贸n. Si est谩 utilizando la configuraci贸n de XML Spring, entonces es necesario agregar esta jpa:repositoriesdeclaraci贸n en su archivo XML contexto de aplicaci贸n, por ejemplo: <jpa:repositories base-package="com.demo.repositores"/>.

    El base-packageatributo le dice a Spring Data JPA qu茅 paquetes debe escanear para buscar repositorios JPA. Debe configurar el base-packageen la estructura del paquete ra铆z de su proyecto, o un paquete que se sepa que contiene sus repositorios JPA.

    La otra forma en que puede configurar Spring Data JPA es usar la @EnableJpaRepositoriesanotaci贸n. Esta es la forma preferida si est谩 utilizando Spring Boot o una configuraci贸n de Java con Spring en lugar de una configuraci贸n XML.

    Repositorios de Spring

    Spring ha apoyado el concepto de repositorio desde hace alg煤n tiempo. Repositoryes uno de los estereotipos centrales de Spring y debe planear usarlos en su capa de acceso a datos, independientemente de la API y el marco de la capa de acceso a datos elegidos.

    El objetivo del repositorio es definir un contrato que implementar谩 su capa de acceso a datos. Este contrato, o m谩s bien la interfaz, se puede incluir y vincular mediante el c贸digo del cliente que necesita acceder a los datos de alguna manera. Lo que esto realmente significa es que un repositorio de Spring es esencialmente una implementaci贸n del patr贸n de objeto de acceso a datos.

    Al definir una interfaz que utiliza el c贸digo de superficie, la capa de acceso a datos es libre de implementar el contrato DAO de todos modos.

    Eso puede significar que cuando comenz贸 su proyecto implement贸 su capa de acceso a datos con JPA. Quiz谩s en alg煤n momento m谩s adelante en el proyecto, necesit贸 reemplazar esa implementaci贸n con la implementaci贸n de JDBC en lugar de JPA. Cuando cambia la implementaci贸n de la interfaz, el c贸digo de servicio del cliente ni siquiera not贸 o le import贸 que algo cambiara en la implementaci贸n en su capa de acceso a datos. Y qui茅n sabe, tal vez en alg煤n momento en el futuro, tendr谩 que cambiar su implementaci贸n de JDBC con otra cosa. Este patr贸n le permite configurar capas de acceso a datos h铆bridos.

    Su implementaci贸n puede realizar algunas operaciones utilizando JPA mientras utiliza JDBC para otras operaciones. La definici贸n m谩s pura de un patr贸n DAO dir铆a que necesita definir un contrato con una interfaz. Los repositorios de Spring, sin embargo, no necesariamente tienen que ser una interfaz.

    Descripci贸n general de la arquitectura del repositorio

    Los repositorios encajan en la capa de acceso a datos, pero no son los 煤nicos objetos y conceptos que debe tener en cuenta cuando trabaja en el lado del servidor. Veamos una aplicaci贸n Spring t铆pica desde un punto de vista arquitect贸nico para ver c贸mo encaja todo.

    Su base de datos generalmente consta de una o m谩s tablas. Pueden o no estar relacionados, como una relaci贸n de padres o hijos. Todas estas estructuras viven en la base de datos, que normalmente es un servidor independiente separado del c贸digo de la aplicaci贸n y del servidor.

    A medida que avanzamos hacia nuestra capa de acceso a datos, tenemos entidades JPA asignadas a tablas de base de datos. Las entidades se asignan una a una con un repositorio JPA. Al mantener el repositorio enfocado en una sola entidad, mantiene el patr贸n DAO limitado a esa estructura de datos y datos espec铆ficos.

    Con los repositorios est谩ndar de Spring, no es necesario que siga este est谩ndar. T茅cnicamente, puede hacer que el repositorio acceda a cualquier cosa y a todo en el lado de los datos. Pero con los repositorios JPA de Spring Data, el repositorio est谩 limitado a una sola entidad JPA.

    Los servicios de Spring se pueden usar para realizar paquetes l贸gicos de trabajo para la aplicaci贸n. La @Serviceanotaci贸n de Spring es otro estereotipo de Spring y lo usar铆a en clases e interfaces que viven en su capa de servicio.

    Y por 煤ltimo, su aplicaci贸n generalmente tendr谩 alg煤n tipo de capa de controlador que maneja el enrutamiento de solicitudes provenientes de la interfaz de usuario. Estos controladores pueden utilizar uno o m谩s servicios y son responsables de devolver una respuesta a la interfaz de usuario o al nivel de presentaci贸n.

    Nota: Lo importante que debe recordar es que las dependencias y enlaces de su c贸digo solo deben moverse hacia la derecha en este diagrama. Por lo tanto, los controladores pueden inyectar servicios o repositorios y los servicios pueden inyectar repositorios, pero los servicios y los repositorios nunca deber铆an inyectar controladores.

    Repositorios Spring Data JPA

    Est谩 empezando a ver que los repositorios Spring est谩ndar y los repositorios Spring Data JPA difieren ligeramente en concepto y estructura.

    Estas son las principales diferencias:

    • Interfaz Java en lugar de una clase
    • Mapa 1 a 1 con una entidad JPA
    • Centrarse en el contrato DAO

    Primero, todos los repositorios JPA son interfaces Java en lugar de clases. Estas interfaces est谩n asociadas con una entidad JPA. Cada repositorio de JPA solo puede realizar operaciones de acceso a datos para esa entidad en particular y sus atributos de datos. Esto ayuda a enfocar el repositorio JPA en el contrato DAO para esa entidad y sus datos de respaldo. 驴C贸mo se relacionan los repositorios JPA con una entidad JPA en particular? Esto se logra utilizando gen茅ricos de Java y escribiendo:

    public interface MyJpaRepository extends JpaRepository<Entity, Id Type> {}
    

    Al proporcionar la entidad JPA y su tipo de datos de clave principal, el repositorio de JPA ahora sabe exactamente con qu茅 tabla de base de datos en columnas puede trabajar porque toda esa informaci贸n est谩 bien empaquetada dentro de su entidad JPA.

    La 煤ltima gran diferencia entre los repositorios Spring Data JPA y los repositorios Spring est谩ndar es c贸mo la implementaci贸n cumple con el patr贸n DAO.

    El patr贸n DAO le permite implementar el contrato DAO como lo desee, y esa implementaci贸n depende de usted. Con los repositorios Spring Data JPA, ya no nos importan los detalles de implementaci贸n, ya que el marco nos lo proporcionar谩. Esto nos permite, como desarrolladores, centrarnos en el contrato DAO mientras cumplimos con el objetivo de Spring Data JPA de simplificar nuestra capa de acceso a datos sin p茅rdida de funcionalidad.

    La gran conclusi贸n que debe recordar es que cuando su aplicaci贸n se inicia, Spring Data JPA reconoce su repositorio JPA y genera autom谩ticamente una implementaci贸n para el contrato DAO que se especifica en esa interfaz.

    Funciones de JpaRepository

    Cuando ampl铆a la interfaz del repositorio JPA, tambi茅n obtiene acceso a un mont贸n de otras funciones. La funcionalidad que viene con el repositorio JPA incluye las operaciones CRUD que ver谩 m谩s adelante en los ejemplos de c贸digo y tambi茅n contiene la funcionalidad Query DSL que cubriremos m谩s adelante en el art铆culo.

    Funcionalidad

    • Consulta DSL
    • Operaciones CRUD
    • Paginaci贸n y clasificaci贸n
    • Ayudantes
      • contar()
      • existe (identificaci贸n larga)
      • enjuagar()
      • deleteInBatch (entidades iterables)

    Tambi茅n hay capacidades de paginaci贸n y clasificaci贸n y, por 煤ltimo, el repositorio de JPA contiene algunos ayudantes que pueden hacer que trabajar con su capa de acceso a datos sea mucho m谩s f谩cil. Algunos de estos incluyen encontrar el recuento de su tabla de base de datos de respaldo, probar si existe un registro en la base de datos, vaciar sus cambios de contexto de persistencia en la base de datos y manejar la eliminaci贸n de m煤ltiples entidades con una sola consulta usando el deleteInBatch()m茅todo pr谩ctico .

    Si echas un vistazo a la jerarqu铆a de interfaces del repositorio JPA, ver谩s que hay tres interfaces principales m谩s desde las que se extiende el repositorio JPA.

    Ver谩 que cuando se combina en una estructura jer谩rquica, todas las funciones de las que hemos hablado para el repositorio JPA comienzan a tener sentido. Lo bueno de dividir la funcionalidad en interfaces separadas es que le brinda la oportunidad de reducir la funcionalidad en su capa de acceso a datos si es necesario.

    Tal vez solo desee tener operaciones CRUD disponibles en su repositorio, por lo que, en ese caso, simplemente puede extender el repositorio CRUD en lugar del repositorio JPA. Una 煤ltima cosa a tener en cuenta sobre la jerarqu铆a del repositorio JPA es que la JpaRepositoryinterfaz es la 煤nica interfaz en el proyecto Spring Data JPA. Las otras tres interfaces en realidad provienen del proyecto de datos principal de Spring.

    Ejemplo de c贸digo

    En esta secci贸n, crearemos un ejemplo simple de Spring Boot para que podamos implementar Spring Data JPA y REST dentro de nuestra aplicaci贸n.

    Elija su IDE favorito (por ejemplo, Eclipse e IntelliJ IDEA tienen Spring Initializr integrado para las dependencias de configuraci贸n). Para generar el proyecto Spring Boot, tambi茅n puede consultar Spring Initializr para iniciar su aplicaci贸n con dependencias.

    En el pom.xmlarchivo, agregamos algunas dependencias m谩s para nuestro proyecto simple, como la spring-webque nos proporciona Spring MVC y Spring Rest, base de datos H2 y JPA:

    <dependencies>
    
        <!-- JPA dependency-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
    
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <scope>runtime</scope>
        </dependency>
    
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    
    </dependencies>
    

    Creamos una clase de controlador llamada UserControllerque contiene la @RestContolleranotaci贸n. Esta anotaci贸n le dice a Spring MVC que este es el controlador y que tiene un punto final de descanso. Es pr谩cticamente el equivalente a escribir ambos @Controllery @ResponseBody.

    El controlador tambi茅n contiene un @RequestMapping("/users")para mapear una HTTPsolicitud a un m茅todo o una clase, un GETm茅todo, un POSTm茅todo y un @Autowired UserJpaRepositoryobjeto.

    @RestController
    @RequestMapping("/users")
    public class UserController {
    
        @Autowired
        private UserJpaRepository userJpaRepository;
    
        @GetMapping(value = "/all")
        public List<Users> getAll(){
            return userJpaRepository.findAll();
        }
    
        @PostMapping(value = "/load")
        public Users load(@RequestBody final Users users) {
            return userJpaRepository.save(users);
        }
    }
    

    Ahora, 驴c贸mo obtenemos los datos de la base de datos? Pasemos a la definici贸n de la interfaz del repositorio UserJpaRepositoryque extiende ‘JpaRepository’.

    En el interior JpaRepository<Users, Long>pasamos el modelo y su Id. En el ejemplo del controlador, estamos usando ‘findAll ()’ para obtener todos los registros de la base de datos y ‘save ()’ para guardarlos.

    public interface UserJpaRepository extends JpaRepository<Users, Long> {}
    

    La Usersclase modelo ser谩 nuestra entidad. La clase en s铆 est谩 anotada con @Entity, la idvariable est谩 anotada con @Id y @GeneratedValue.

    • La @Entityanotaci贸n mapear谩 este POJO en la base de datos con todos sus campos.
    • La @Idanotaci贸n marca el campo como la clave principal de la tabla.
    • La @GeneratedValueanotaci贸n pr谩cticamente establece la AUTO_INCREMENTopci贸n de la clave principal en verdadera. Opcionalmente, puede agregar (strategy = GenerationType.AUTO)para lograr esto.
    @Entity
    public class Users {
    
        @Id
        @GeneratedValue
        private Long id;
    
        private String name;
        private Integer salary;
    
        // getters and setter
    }
    

    Despu茅s de iniciar la aplicaci贸n, navegue a ‘localhost: 8080 / users / all’ para obtener todos los usuarios, y no deber铆a recibir nada como puede ver en la imagen a continuaci贸n porque no tiene ning煤n usuario en la base de datos de memoria H2.

    A continuaci贸n, vaya a su herramienta de cliente REST favorita (la imagen a continuaci贸n muestra un ejemplo de Postman ). Como puede notar, estamos usando el m茅todo POST de nuestro controlador que guardar谩 los datos.

    Agregamos nombre y salario y enviamos la solicitud POST. El idse genera autom谩ticamente, como puede ver en el cuerpo de la respuesta.

    La aplicaci贸n respondi贸 con un Estado 200 OK. 隆Todo funciona como deber铆a! De esta forma, puede agregar tantos usuarios como desee.

    Nota: Despu茅s de reiniciar la aplicaci贸n, todos los datos se perder谩n porque estamos usando una base de datos en memoria.

    Ahora vaya de localhost:8080/users/allnuevo a GETtodos los registros de usuario de la base de datos y deber铆a ser recibido con:

    Informaci贸n general sobre consultas DSL

    De todas las funciones que ofrece Spring Data JPA, la funci贸n Query DSL en el repositorio JPA es una de las m谩s potentes, flexibles y pertinentes para las necesidades de lectura y consulta de acceso a datos de su aplicaci贸n.

    Debido a que Query DSL es extremadamente personalizable y se basa en su entidad JPA, tambi茅n puede ser uno de los aspectos m谩s dif铆ciles de Spring Data JPA para captar y volverse eficiente.

    Ventajas de utilizar un DSL de consulta

    Algunas de las ventajas de utilizar un DSL de consulta es que le permitir谩 sobrescribir consultas y buscadores personalizados.

    Primero, piense en todos los esfuerzos que ha dedicado a mapear entidades JPA a las tablas de su base de datos. Si tiene un esquema de base de datos grande, configurar sus entidades JPA puede requerir algo de trabajo. Su capa de entidad contiene mucha informaci贸n sobre las tablas de la base de datos a las que se asigna.

    Por ejemplo, JPA conoce el nombre de la tabla, las columnas y los tipos de datos de las columnas, todo al observar las anotaciones de la entidad, los atributos y los tipos de datos de los atributos. Si ha hecho un esfuerzo adicional con el mapeo de su entidad, puede especificar restricciones en las relaciones que le brindan a煤n m谩s conocimiento sobre su base de datos desde el nivel del software. 驴Por qu茅 tirar todo este conocimiento para tener que implementar consultas y buscadores manualmente?

    Deje que un marco como Spring Data JPA use esta informaci贸n para que pueda definir el contrato de consulta y dejar que el marco proporcione la implementaci贸n. Debido a que no estamos agregando c贸digo de implementaci贸n, eso nos libera como desarrolladores de aplicaciones de tener que mantener ese c贸digo.

    Con el tiempo, recolecta herramientas y otros art铆culos diversos y, despu茅s de un tiempo, se encontrar谩 limpiando, ordenando y organizando su garaje un s谩bado. Por lo tanto, desde el punto de vista del desarrollo de aplicaciones, no pierda su precioso tiempo del s谩bado limpiando su garaje. Deje que Spring Data JPA se ocupe de su problema de implementaci贸n mientras pesca o hace otra cosa.

    Otra ventaja de ahorrar tiempo al usar Spring Data JPA Query DSL es que el marco verifica la validez de sus consultas cuando se inicia la aplicaci贸n, en lugar de en tiempo de ejecuci贸n. Esto ahorra tiempo al no tener que buscar y probar realmente el punto en su aplicaci贸n al que ha llamado la consulta.

    Las comprobaciones de inicio de la aplicaci贸n tambi茅n protegen contra cambios de refactorizaci贸n. Si un atributo de entidad cambia, sabr谩 r谩pidamente si eso rompi贸 alguna de sus consultas cuando inicie su aplicaci贸n.

    Por 煤ltimo, las consultas DSL se han utilizado en plataformas de lenguaje de secuencias de comandos durante mucho tiempo. El marco de registro activo de Ruby on Rails o la pila ORM de Django son buenos ejemplos de esto. Java ha tardado en adoptar esta metodolog铆a debido a su naturaleza compilada y de verificaci贸n de tipos. Es f谩cil agregar funcionalidad sobre la marcha en un lenguaje de secuencias de comandos porque los clientes que lo utilizan no se comprueban ni compilan.

    Esto le da a los lenguajes de script mucha flexibilidad en esta 谩rea en particular. Spring Data JPA ha encontrado un equilibrio bastante bueno al requerir que el desarrollador defina el contrato de datos, y luego el marco puede implementar ese contrato como lo har铆an Rails o Django. El c贸digo del cliente se puede vincular y compilar con ese contrato de interfaz.

    Y antes de continuar, asegur茅monos de tener claro qu茅 es un DSL. DSL es un acr贸nimo de D Omain S ESPEC脥FICOS L anguage. Este es un t茅rmino que se utiliza para clasificar una extensi贸n de un lenguaje de programaci贸n para abordar un dominio. En el caso de Spring Data JPA, esto significa que el marco est谩 mejorando Java para que sea m谩s adecuado para crear y trabajar con consultas JPA.

    Usamos un lenguaje espec铆fico de dominio en el habla todo el tiempo. Los m茅dicos tienen t茅rminos y palabras que los ayudan a trabajar de manera m谩s eficiente, y lo mismo para los abogados o los trabajadores de la construcci贸n, o cualquier industria. Spring Data JPA Query DSL se trata simplemente de definir t茅rminos y sintaxis para trabajar con consultas JPA de manera m谩s eficiente.

    Sintaxis del m茅todo de consulta

    Repasemos los conceptos b谩sicos de la sintaxis necesaria para que estos m茅todos de consulta funcionen. Primero, los m茅todos de consulta son simplemente m茅todos definidos en su repositorio JPA que Spring Data JPA implementar谩 autom谩ticamente en su nombre. Son una forma en que Spring Data JPA puede implementar consultas por usted.

    Cuando se crea un m茅todo de consulta, el analizador de consultas buscar谩 m茅todos que comienzan con find, query, read, count, o get. Estos prefijos se pueden mejorar con otras palabras clave hasta que, eventualmente, llegue a la B-Yo Byuna secci贸n del nombre del m茅todo.

    Esto indica que el criterio, o parte del filtro, de la consulta est谩 comenzando y Spring Data JPA hace coincidir los atributos de entidad de los criterios del m茅todo con la WHEREcl谩usula real en su SQL Se pueden agregar m煤ltiples definiciones de criterios al nombre de su m茅todo con las palabras clave Ando Or.

    Esto puede sonar un poco confuso, as铆 que veamos la consulta de ubicaci贸n en el c贸digo a continuaci贸n.

    public interface LocationJpaRepository extends JpaRepository<Location, Long> {
        findByAgeLike(Integer age);
    }
    
    • find– El m茅todo comienza con findpara que el analizador de consultas comprenda que necesita implementar este contrato de consulta.
    • By – Siguiendo la palabra clave anterior, agregamos esta que indica que la informaci贸n de los criterios aparecer谩 a continuaci贸n en el nombre del m茅todo.
    • Age– Luego, lo especificamos m谩s. Agecoincide con el nombre del atributo age en la entidad JPA de mi ubicaci贸n, y la edad es del tipo de datos Integer.
    • Like – La palabra clave final le dice a la implementaci贸n que queremos crear una consulta Me gusta, en lugar de una coincidencia exacta.

    Luego paso una Integervariable que la implementaci贸n de la consulta deber铆a usar como criterio de filtro real. Es de tipo Integerporque nuestro tipo de datos de edad en la entidad de ubicaci贸n es de tipo Integer.

    Al unir las palabras clave DSL de la consulta junto con la escritura de gen茅ricos del repositorio JPA, puede ver c贸mo Spring Data JPA puede generar el JPQL para nosotros.

    Esto, a su vez, se asigna al SQL real que se emitir谩 contra la base de datos gracias al marco JPA ORM.

    Palabras clave

    KeywordSampleJPQL Snippet

    YfindByLastnameAndFirstname… donde x.lastname =? 1 y x.firstname =? 2
    OfindByLastnameOrFirstname… donde x.lastname =? 1 o x.firstname =? 2
    Es igual afindByFirstnameEquals… donde x.firstname =? 1
    EntrefindByStartDateBetween… donde x.startDate entre? 1 y?
    Menos quefindByAgeLessThan… donde x.age
    Menos que igualfindByAgeLessThanEqual… donde x.age
    =>
    Mas grande quefindByAgeGreaterThan… donde x.age>? 1
    Mayor que igualfindByAgeGreaterThanEqual… donde x.age> =? 1
    Despu茅sfindByStartDateAfter… donde x.startDate>? 1
    antes defindByStartDateBefore… donde x.startDate
    Es nulofindByAgeIsNull… donde x.age es nulo
    IsNotNull, NotNullfindByAge (Is) NotNull… donde x.age no es nulo
    Me gustafindByFirstnameLike… donde x.firstname como? 1
    Diferente afindByFirstnameNotLike… donde x.firstname no me gusta? 1
    Empezando confindByFirstnameStartingWith… donde x.firstname como? 1 (par谩metro enlazado con% a帽adido)
    Terminando confindByFirstnameEndingWith… donde x.firstname como? 1 (par谩metro enlazado con% antepuesto)
    ConteniendofindByFirstnameContaining… donde x.firstname como? 1 (par谩metro enlazado envuelto en%)
    OrderByfindByAgeOrderByLastnameDesc… donde x.age =? 1 orden por x.lastname desc
    NofindByLastnameNot… donde x.lastname? 1
    EnfindByAgeIn (edades de la colecci贸n)… donde x. edad en? 1
    No enfindByAgeNotIn (edades de la colecci贸n)… donde no x.age? 1
    CiertofindByActiveTrue ()… donde x.active = true
    FalsofindByActiveFalse ()… donde x.active = false
    Ignorar casofindByFirstnameIgnoreCase… donde UPPER (x.firstame) = UPPER (? 1)

     

    Etiquetas:

    Deja una respuesta

    Tu direcci贸n de correo electr贸nico no ser谩 publicada. Los campos obligatorios est谩n marcados con *