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 *