En Spring Data Couchbase proyecto comunitario se ha construido históricamente sobre la 1.4 generación del funcionario SDK Java de Couchbaseaunque el SDK 2.0 hace ya bastante tiempo.
Pero ahora es un buen momento para actualizar Spring Data Couchbase al último SDK 2.2, sobre todo porque es el que tiene soporte para N1QLtambién conocido como "SQL para documentos", el nuevo lenguaje de consulta de Couchbase.
La generación 2.x SDK es una reescritura completa, construida sobre una capa totalmente asíncrona y exponiendo RxJava Observables para la API async. Como tal, tiene un nombre de artefacto de Maven independiente y garantiza una versión principal de Spring Data Couchbase.
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 cubo diferente, o incluso a un clúster). - La copia de seguridad de los métodos personalizados no siempre se realiza con
vistasya no, ahora se hace por defecto más bien a través deN1QLque es mucho más flexible y requiere mucho menos mantenimiento por parte del servidor. - Métodos personalizados con
vistasse han modificado un poco para ceñirse mejor a la filosofía de Spring Data. Esto reduce la flexibilidad, pero las implementaciones se generan a partir del nombre del método ("derivación de consultas“). - Ahora es posible reducir la vista.
- Cambiar el nombre del campo JSON que almacena la información de tipo ("
Clase"). Por ejemplo, unPasarela de sincronización-compatible,javaClassse ofrece enMappingCouchbaseConverter.TYPEKEY_SYNCGATEWAY_COMPATIBLE.
Por supuesto, puede seguir accediendo a la API de nivel inferior mediante la función CouchbaseTemplate en lugar de CouchbaseRepository e incluso se puede acceder a la interfaz subyacente Cubo del SDK.
Profundicemos un poco más en estos cambios.
Métodos de repositorio a través de N1QL
La gran novedad de Couchbase 4.0 es N1QLun superconjunto de SQL que funciona con documentos JSON (por lo que añade a SQL especificidades relacionadas con JSON).
Esto es especialmente bueno para el patrón Repository y la derivación de consultas en Spring Data, porque la gran mayoría de las palabras clave de derivación de consultas también se traducen fácilmente a N1QL.
N1QL es ahora la característica por defecto de respaldo de Couchbase para los métodos de Repositorio. También puede optar por utilizar la función @Query si quiere ser explícito.
Por ejemplo, un método derivado de una consulta utilizando N1QL podría tener el siguiente aspecto:
A su vez, para los parámetros "fruta", "tarta de queso", 5, nos da una consulta N1QL parecida a:
Como puede ver, el framework incluso elegirá correctamente qué campos seleccionar (incluidos los metadatos) para poder desmarcar el documento en un archivo PartyCake entidad.
En cuanto a las opiniones, primeroX sintaxis para LÍMITE y countBy en lugar de findAllBy hacer un SELECT COUNT(*) también son compatibles.
Otra ventaja frente a las vistas es que puedes tener un único índice de propósito general (un "índice primario" desde la perspectiva de N1QL) y usarlo para todas tus consultas, por lo que esto supone menos ajuste del lado del servidor en comparación con las vistas, donde cada consulta diferente necesitará una vista diferente.
Nota: por supuesto también puedes crear índices secundarios más especializados y eficientes en N1QL.
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 puede hacer es utilizar derivación de consultas para las consultas más sencillas.
Esto significa que puedes hacer algo así:
El framework tomará esa interfaz y creará una consulta a partir del nombre del método y los parámetros dados. Por ejemplo, si se llama con un Lista de fruta y azúcar dará como resultado una consulta como ?keys=["fruit","sugar"].
Consulte la documentación para obtener una lista exhaustiva de las palabras clave de su nombre de método que pueden traducirse en un parámetro de consulta. Para cualquier otro uso, debes proporcionar la implementación tú mismo.
Uso de la función de reducción de Views
Otra novedad que antes no se admitía es la ejecución del reducir la función si tiene uno. Ahora, para ejecutarlo, basta con declarar un método que empiece por cuente en lugar de findAllque devuelve un long.
Tenga en cuenta que la función de reducción en Couchbase puede ser otra que la preexistente Cuenta siempre que devuelva un long.
Del mismo modo, si se añade la variación "topX" o "primeroX" en el nombre de un método se producirá un error adicional límite que se establece en la solicitud (p. ej. 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 Lea sus propios escritos.
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 un medio global de configurar que para todas las consultas (basadas en vistas o en N1QL) que son construidas por el marco a través de la derivación de consultas, proporcionando una pequeña abstracción en torno al concepto de Coherencia.
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.
También puede hacerlo en XML utilizando la función coherencia del atributo etiqueta.
Modificación del campo de información de tipo en JSON almacenado
Por último, algunos usuarios han informado de problemas con Spring Data y la parte de Couchbase Mobile, con la función Pasarela de sincronización rechazar documentos que contengan campos precedidos por un guión bajo.
Esto es problemático ya que Spring Data almacena la información de tipo en un archivo Clase campo :(
La solución es permitir, a través de la configuración, elegir 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.
Configuración
El SDK 2.0 está ahora más cerca de la terminología de un cluster Couchbase, con objetos como Grupo y Cubo como ciudadanos de primera clase. Como resultado, en la Configuración de Datos de Spring en lugar de un CouchbaseClient configurar frijoles más diversos.
El ajuste del SDK se realiza en una clase separada, la clase CouchbaseEnvironmentque le permite ajustar los grupos de io, los tiempos de espera, etc. Los entornos deben reutilizarse en la medida de lo posible en todos los entornos. Grupos, y Grupos se deben reutilizar para abrir archivos singleton Cubos (todo debe reutilizarse en la medida de lo posible, básicamente).
Para obtener un CouchbaseTemplatese necesita un Medio ambiente, a Grupo y un Cubo. Todos ellos se crean automáticamente al ampliar JavaConfig AbstractCouchbaseConfigurationlo único que tiene que proporcionar son:
- la lista de nodos desde los que arrancar (sólo las IP o los nombres de host)
- el nombre del cubo
- la contraseña del cubo
Por supuesto, si desea anular, por ejemplo, el valor predeterminado Medio ambiente puede anular los métodos correspondientes en la configuración de AbstractCouchbaseConfiguration (como se muestra en el siguiente fragmento):
El equivalente en xml es:
Configuración del servidor
Métodos CRUD de Spring Data Couchbase obtenidos de un CrudRepository siguen estando respaldadas por las operaciones Clave/Valor de Couchbase (cuando se trabaja con entidades únicas o entidades mutantes), o por una interfaz ver (cuando trabajamos con varias entidades de las que no conocemos el ID, por ejemplo para contar() o findAll() métodos).
Esto significa que usted todavía tiene que tener un índice de todas sus entidades de alguna manera, en la forma de una vista en Couchbase.
Por defecto, el framework buscará el nombre de su entidad, sin mayúsculas, para el documento de diseño y una vista llamada todos (Ej. partyCake/todos para un PartyCake clase de entidad).
Conclusión
Eso es todo (por ahora) para esta primera versión preliminar de Spring Data Couchbase 2.0.x. ¡Espero que os guste!
En documentación del proyecto y el README han sido actualizados con estas nuevas características y todo el código y docs son visibles en el 2.0.x en la rama Spring Data Couchbase Repositorio Github.
Gracias a Oliver del equipo de Spring Data por su apoyo, y a nuestros usuarios que intervinieron y ofrecieron contribuciones o sugerencias de mejora (no es una lista exhaustiva):
vasilievip, KlausUnger, kdheerendra, jloisel, DWvanGeest, ajbrown, wilsondy
Para descargar y utilizar esta vista previa, utilice Maven (tanto con el Primavera instantánea y Couchbase repositorios de instantáneas):
