Lanzamiento de Spring Data Couchbase 2.0 RELEASE

Spring Data Couchbase 2.0 es una reescritura del conector Spring Data Couchbase 1.4.x original. Se basa en el SDK Java 2.2 de Couchbase y hace un uso intensivo del nuevo lenguaje de consulta N1QL (que se introdujo en Couchbase Server 4.0) para ofrecer más funciones a los usuarios de Spring Data.

En Primer hito se publicó el pasado mes de agosto, a continuación se lanzó una versión candidata y, desde entonces, se han implementado nuevas funciones (y se han corregido errores).

Hagamos un rápido recorrido por lo que ha cambiado (con una notación de ⭐ a ⭐⭐⭐ de lo impresionante y significativa que nos parece cada característica...):

Novedades de Spring Data Couchbase 2.0

Las principales diferencias entre la generación 1.x de Spring Data Couchbase y su versión 2.x son:

• Los elementos de configuración se acercan más a la realidad de Couchbase: Entorno, Cluster, Bucket (permitiendo potencialmente crear CouchbaseTemplates que se conectan cada uno a un bucket diferente, o incluso a clusters diferentes).
• La copia de seguridad de los métodos de repositorio personalizados ya no se hace siempre con vistas, ahora se hace (por defecto) a través de N1QL, que es mucho más flexible y requiere menos mantenimiento del lado del servidor.
• Los métodos personalizados que utilizan vistas se han modificado un poco para ceñirse mejor a la filosofía de Spring Data. Esto reduce un poco la flexibilidad, pero las implementaciones se generan a partir del nombre del método (mediante "derivación de consultas").
• Ahora puede realizar consultas geoespaciales de sus datos (o consultas multidimensionales si va más allá de las 3 dimensiones) con vistas.

Por supuesto, puede seguir accediendo a la API de nivel inferior mediante la función CouchbaseTemplate en lugar del CouchbaseRepository e incluso se puede acceder a la interfaz subyacente Cubo del SDK.

Métodos de repositorio a través de N1QL

⭐⭐⭐

La gran novedad de Couchbase 4.0 es N1QL, una extensión de SQL que funciona con documentos JSON (por lo que añadía a SQL especificidades relacionadas con JSON).

Esto es especialmente bueno para los Repositorio y derivación de consultas en Spring Data, porque la gran mayoría de las palabras clave de derivación de consultas se pueden traducir fácilmente a N1QL.

N1QL es ahora la función de respaldo por defecto de Couchbase para los métodos de Repositorio. También puede optar por utilizar la interfaz @Query si desea ser explícito en la consulta ejecutada.

Métodos de repositorio a través de Views

⭐⭐

Un gran cambio en esta versión es que ahora, las consultas de repositorio (también conocidas como métodos de repositorio personalizados) que se basan en vistas están más en línea con la filosofía de Spring Data. También tienen que ser anotados explícitamente con @View(viewName="algo").

Esto significa que nada específico de Couchbase debería filtrarse en la interfaz de tu repositorio. En su lugar, lo que puedes hacer es utilizar mecanismos de derivación de consultas para la mayoría de las consultas.

La derivación de consultas también es posible en pequeña medida, con la aceptación de unas pocas palabras clave en un método basado en vistas.

Uso de la función de reducción de Views

⭐

Otra novedad que antes no se soportaba es la ejecución de la función reducir si se dispone de ella. Ahora, para ejecutarla, basta con establecer el parámetro reducir a true en el Ver anotación.

También puede anteponer a su método el prefijo "count" en lugar de "find" si le resulta útil (es decir, si realmente utiliza la función de reducción "count").

Tenga en cuenta que la función de reducción en Couchbase puede ser algo diferente a la preexistente _count, e incluso podría devolver algo diferente a un long como un JsonObjectcomo por ejemplo Estadísticas.

Del mismo modo, si se añade la variación "topX" o "firstX" en el nombre de un método, se establecerá un límite adicional en la solicitud (por ejemplo. findFirst5ByLastName limitará la lista a 5 resultados).

Configurar la coherencia, leer sus propios escritos

⭐⭐⭐

Una cosa que surge a menudo cuando se utilizan índices secundarios poblados asíncronamente como vistas y GSI (el nuevo motor de índice secundario que respalda a N1QL), es la necesidad de leer inmediatamente las modificaciones de sus operaciones de escritura anteriores.

Esto implica que la vista/N1QL no debe responder mientras los datos estén aún en proceso de indexación, por lo que se sacrifica algo de rendimiento en favor de la consistencia.

Lo contrario (y por defecto en Spring Data Couchbase) es favorecer el rendimiento aceptando que se devuelvan datos obsoletos.

Hemos añadido una semántica global para configurar todas las consultas (basadas en vistas o en N1QL) que son construidas por el framework a través de la derivación de consultas, proporcionando una pequeña abstracción en torno al concepto de Consistencia.

Esto se hace anulando la función AbstractCouchbaseConfiguration's getDefaultConsistency() método. Coherencia es un enum que permite elegir entre LEER_ESCRITURAS_PROPIAS, FUERTEMENTE_CONSISTENTE, UPDATE_AFTER y EVENTUALMENTE_CONSISTENTE. Consulte la documentación oficial para obtener más información sobre cómo funcionan exactamente y cuál es su impacto en el momento de la consulta.

También puede hacerlo en XML utilizando el atributo de coherencia en la variable etiqueta.

Desde GA, los métodos CRUD en repositorios ahora también tienen en cuenta la consistencia configurada por defecto.

Modificación del campo de información de tipo en JSON almacenado

⭐

Algunos usuarios han informado de problemas con Spring Data y la parte de Couchbase Mobile, con la puerta de enlace de sincronización rechazando documentos que contienen campos prefijados por un guión bajo.

Esto es problemático para Spring Data, ya que por defecto almacena la información de tipo en un archivo Clase campo :(

La solución es permitir, a través de la configuración, modificar el nombre de ese campo de información de tipo. Puede hacerlo anulando la directiva typeKey() método en AbstractCouchbaseConfiguration. Por ejemplo, puede utilizar la constante MappingCouchbaseConverter.TYPEKEY_SYNCGATEWAY_COMPATIBLE (que es "javaClass“).

Este campo es el que utilizan las consultas N1QL generadas para filtrar sólo los documentos correspondientes a la entidad del repositorio.

Apoyo a Pageable/Petición de página en las consultas derivadas de N1QL

⭐⭐

Utilizando N1QL, para consultas que se generan a través de la derivación de consultas, Pageable y Ordenar ahora son compatibles.

• Apoyo a PagingAndSortingRepository basado en N1QL.
• Añade dos findAll que dependen de N1QL para la paginación y/o la ordenación. Utiliza la coherencia configurada por defecto.

Consultas geoespaciales y multidimensionales mediante vistas espaciales

⭐⭐⭐

Consulta Couchbase usando coordenadas Siempre que su entidad tenga un Punto (o x y y), puede encontrarlo utilizando

• un cuadro delimitador: findByLocationWithin(Caja área)
• un círculo: findByLocationWithin(Círculo área), findByLocationWithin(Punto centro, Distancia radio).
• un polígono: findByLocationWithin(Polígono área), findByLocationWithin(Punto[] polígono).
• a distancia findByLocationNear(Punto cercano, Distancia maxDistancia).

Las consultas sobre círculos y polígonos se realizan rápidamente en el servidor como aproximaciones de cajas delimitadoras y, a continuación, el marco elimina los falsos positivos antes de presentar los resultados.

Puede aprovechar el aspecto multidimensional de Couchbase Spatial Views para añadir dimensiones adicionales a sus consultas (por ejemplo, tiendas que abren tarde por la noche dentro de una ciudad...).

Nota: si desea reutilizar las anotaciones, también puede hacerlo (funciona para Ver y @Query también):

En línea N1QL @Query ahora son compatibles con SpEL

⭐⭐⭐

Las consultas en línea pueden utilizar la notación SpEL para:

1. asegurarse de que se aplica la selección y el filtrado correctos a la sentencia para construir y devolver entidades: utilizar #{#n1ql.selectEntity} para generar un SELECT ... FROM ... y #{#n1ql.filter} en el DONDE para limitar la consulta a la entidad correcta.
2. calcular valores o recuperar datos de proveedores de valores SpEL externos configurados en el contexto de Spring.

La creación de índices "principales" del repositorio puede activarse automáticamente

⭐⭐

⚠️ IMPORTANTE: esto se considera una ayuda durante el desarrollo/pruebas y se desaconseja en producción.

Para asegurarse de que la indexación N1QL de las entidades de un repositorio determinado está activada en un entorno de desarrollo o preproducción, se puede anotar con @N1qlPrimaryIndexed (que permite realizar consultas de forma libre en todo el bucket) y @N1qlSecondaryIndexed (que indexará sólo los documentos correspondientes al tipo de entidad, de forma similar a la cláusula WHERE producida por SpEL #{#n1ql.filter}).

Además, la vista de respaldo para la operación CRUD puede crearse automáticamente anotando el repositorio con @VerIndexado (tendrá que proporcionar el nombre del documento de diseño, que debe corresponder al nombre de clase simple de la entidad con la primera letra en minúscula).

Esta función debe activarse adicionalmente redefiniendo el campo indexManager judía en el AbstractCouchbaseConfiguration.

Tipos de retorno simples (primitivos y Cadena) cuando se utiliza una proyección de una sola fila

⭐⭐

Esto está especialmente dirigido a las consultas N1QL en línea con funciones de agregación como CONTAR(*), AVG(campo)La consulta debe devolver una única fila con una única proyección.

Soporte de parámetros con nombre en las consultas en línea N1QL

⭐⭐

Utilice parámetros con nombre o parámetros posicionales, pero no ambos. La sintaxis de los parámetros con nombre es $paramNameque requiere que cada parámetro del método se anote con @Param("paramNombre").

Otras características

⭐

Otras características son:

• Arreglar la nomenclatura de los beans para que todos los beans creados por Spring Data Couchbase lleven el prefijo "couchbase", para evitar enfrentamientos con otras tiendas.
• Ahora es posible cambiar la clase base de todos los repositorios (siguiendo el proceso documentado en la documentación común de Spring Data).
• En caso de que los índices estén obsoletos, los documentos borrados se eliminan de los métodos de búsqueda en el archivo CouchbaseTemplate
• La caducidad puede fijarse en un @Documentocomo largo + timeUnit

También se han implementado algunas correcciones de errores y mejoras con respecto a la RC1.

Documentación

⭐⭐⭐

Documentación también se ha mejorado, añadiendo ejemplos orientados a Couchbase sobre cómo añadir la implementación de un método personalizado a un repositorio, cómo cambiar la clase base de todos los repositorios, cómo tratar con SpEL en consultas en línea, ...

Nota sobre Spring Cache

En Caché de primavera ha salido del repositorio de Spring Data. Todavía está ahí y planeamos mejorarlo. Por ahora puedes encontrarlo en Couchbase repositorio en github pero pronto debería reintegrarse a la familia oficial de proyectos Spring.

Obtener Spring Data Couchbase

Puede añadir lo siguiente a su proyecto pom.xml para obtener esta versión GA (en el dependencias sección:

Esperamos que disfrute de esta versión y de todas las novedades que aporta. El siguiente paso será volver a conectar con el Tolva tren de liberación con una versión 2.1 antes del verano.