Couchbase Java SDK 2.2 Developer Preview 1

En nombre del equipo del SDK, tengo el placer de presentar la próxima gran versión del SDK de Java, el Versión 2.2. El equipo ha estado trabajando duro para traerte nuevas e increíbles funciones, y hoy creemos que es el momento de arrojar algo de luz sobre ellas publicando una primera versión preliminar para desarrolladores.

La versión 2.2 incorpora numerosas novedades:

• Mejorado N1QL soporte
• Simple Asignación de entidades
• Varias API mejoras
• Clases auxiliares para simplificar reintentar manejo de
• Versión protuberancias de algunas dependencias

Saltar al conclusión si no puedes esperar a tener el código en tus manos :)

Cambios relacionados con N1QL

Recientemente se ha publicado la versión 4.0 Developer Preview de Couchbase Server. Entre las muchas características de esta nueva versión, destaca la integración de nuestro nuevo lenguaje de consulta "SQL for Documents" (nombre en clave N1QL) es uno de los principales.

En versiones anteriores del Java SDK, ya teníamos soporte para N1QL (especialmente para la 4ª Developer Preview independiente que fue lanzada por el Query Team a principios de este año), y continuamos de esta manera.

Desde N1QL DP4, hemos ampliado el DSLha añadido un DSL para gestión de índices y añadió compatibilidad con contraseñas de cubo.

Extensión DSL

Se han ampliado y mejorado varias partes de la DSL. Hemos hecho que todo el Tutorial N1QL puede implementarse a través del DSL de Java.

En DESDE puede hacer referencia a los ID de documento mediante la cláusula UTILIZAR TECLAS mientras que otras cláusulas (como ÚNASE A o NEST) se refieren a los identificadores de documento mediante EN TECLAS cláusula.
El DSL existente para eso sólo producía TECLAS que no es suficiente, por lo que ambas variantes se reimplementaron como useKeys/useKeysValues y onKeys/onKeysValues en la DSL.

En N1QL, tenemos el concepto de predicados de colección (o comprensiones) con los operadores ANY, EVERY, ARRAY y FIRST. Hemos introducido un mini-DSL, Coleccionespara construir tales predicados y producir un Expresión que los representa, para utilizarlos en el resto del DSL.

En algunos casos, N1QL ofrece alternativas sintácticas y valores por defecto. Tres de ellos vienen a la mente como hemos abordado tanto un poco diferente:

• el AS la sintaxis de aliasing a veces puede omitir la palabra clave por completo, como en FROM default AS src vs FROM src por defecto. Hemos optado por producir únicamente la forma explícita con el AS (ya que el usuario tiene que llamar a la función as(String alias) de todos modos).
• UTILIZAR TECLAS y EN TECLAS tienen una sintaxis alternativa opcional CLAVES PRIMARIAS DE USUARIO y EN CLAVES PRIMARIAS. Son semánticamente equivalentes y sólo producimos la primera forma.
• ORDENAR POR tiene una dirección de ordenación por defecto en la que no se pide explícitamente DESC ni ASC. Hemos implementado esta opción en el Ordenar con el operador def(Expresión onQueOrdenar) método.

Unas cuantas funciones, algunas de las cuales se implementaron previamente en la aplicación Funciones se han añadido/trasladado a la clase ...query.dsl.functions en clases auxiliares separadas que coincidan con la categoría de las funciones que contienen (p. ej. StringFunctions).

En Expresiónhemos añadido algunos métodos de fábrica para construir Expresiones a partir de un archivo Declaración (como hacer una subconsulta) y construir una ruta:

También hemos añadido operadores aritméticos añada, reste, multiplicar y dividir:

Por último, añadimos otro mini-DSL para el CASO declaración. CASE puede utilizarse para producir resultados alternativos en función de una condición. O bien la condición se hace explícita en cada alternativa CUANDO (la expresión allí es condicional, y esta forma de CASE se denomina "caso de búsqueda"), o la condición es simplemente la igualdad con un identificador/expresión dado al principio del CASE (como CASE usuario.género WHEN "hombre" THEN 1). He aquí un ejemplo del DSL en acción:

DSL de gestión de índices

Si ya has jugado con N1QL, sabrás que puedes crear índices para acelerar significativamente tus consultas. Hasta ahora, la única forma de crearlos mediante programación era emitir una sentencia String sin procesar. Ahora ya no.

El DSL de gestión de índices ofrece soporte para las distintas operaciones relacionadas con los índices, a saber:

Creación de un índice:

Creación de una principal índice:

Índices de caída:

Construir índices que se aplazaron en el momento de la creación:

Observe que la mayoría de los identificadores (nombres de índice, espacio de nombre/espacio de clave) se escapan automáticamente mediante comillas.

Soporte para contraseñas de cubos

Al consultar el servicio N1QL, ahora enriquecemos automáticamente las cabeceras de la solicitud con la información de autenticación obtenida de la llamada Cuboque permite consultar un cubo protegido por contraseña de forma transparente (como ya ocurría con ViewQuerys).

Asignación de entidades

Esta característica ha sido muy solicitada en el pasado: la capacidad de mapear fácilmente un objeto de dominio a un documento Couchbase, y viceversa.

Hemos empezado a explorar este Asignación de entidades (o ODM, Cartografía de documentos objeto) en 2.2. El enfoque consiste en proporcionar una API similar a Cubo dedicada a ODM. Esta API se describe en el Repositorio y se puede obtener un repositorio de un cubo llamando a bucket.repository().

Los métodos de la API del repositorio se ocupan de un nuevo tipo de DocumentoEl DocumentoEntidad. Se adhiere a la semántica Document que separa los metadatos del contenido (su objeto de dominio en este caso). Se espera que el objeto de dominio esté anotado (véase más abajo) para que el mapeo funcione.

DocumentoEntidad puede utilizarse para dar explícitamente un idque se utilizará como clave primaria en Couchbase, pero al contrario que el otro Documento a las que está acostumbrado, esto es opcional. Como alternativa, puede anotar un código Cadena en su clase de dominio con @Id para utilizarlo como identificador del documento. @Id nunca se almacena en el contenido JSON en Couchbase...

Sólo los atributos marcados con @Campo se tienen en cuenta y pasan a formar parte del contenido JSON de la base de datos o se inyectan en el objeto en el momento de su envío. consiga. Esta anotación también puede llevar un alias para el nombre del campo:

Las limitaciones actuales (algunas de las cuales pueden suprimirse en el futuro) son:

• @Campo sólo es compatible con los atributos de tipo básicos (los que pueden añadirse a un atributo JsonObject), y en general este ODM es para casos sencillos. Se está trabajando en el soporte para Mapas, Listas y Conversores personalizados.
• sólo las clases con constructores de carga cero son compatibles con ODM.
• se realiza mediante reflexión para obtener/establecer los valores de los atributos la primera vez (después se almacena internamente en caché).

Mejoras en la API

El actual Cubo La API ha experimentado un par de mejoras.

En primer lugar, se ha introducido una nueva operación para comprobar fácilmente la existencia de una clave sin tener que pagar el coste de la misma consigatando el contenido del documento. Esta es la exist(Cadena clave) método:

En segundo lugar, una función relacionada con vistas que estaba presente en la generación 1.x del SDK pero no en la 2.x es la posibilidad de solicitar una obtención masiva de los documentos al realizar una consulta de la vista (la función incluirDocs opción).

Esto no es realmente difícil de hacer en 2.x cuando se utiliza la función async API (mediante la función patrón de masa que depende de RxJava), pero falta cuando se utiliza la API de sincronización. De hecho, la única forma de obtener el documento correspondiente a cada fila en modo de sincronización es llamar a fila.documento()que bloqueará y disparará una petición por fila, en serie. Esto es bastante ineficiente.

Así que hemos reintroducido el incluirDocs en la API de consulta de vistas. Esto desencadenará una carga asíncrona eficiente del documento de cada fila en segundo plano, de la que también se beneficia la API de bloqueo (las filas ya tendrán el valor Documento en caché al llamar a documento() en ellas). También se puede utilizar en la API asíncrona, pero allí es más o menos un "noop" cuando se llama a .document() en el AsyncViewRow.

Ayuda de reintento

Esto es en realidad algo que era parte de la liberación 2.1.2pero merece una mención en una entrada del blog.

Una de las ventajas de utilizar RxJava es que puede componer operadores Rx con sentido y beneficiarse de primitivas avanzadas de gestión de errores. Entre ellas se encuentra la función reintentar y reintentarCuando que permiten reintentar un flujo asíncrono en diversas condiciones.

Por ejemplo, puede que desee reintentar un consiga solicitud al recibir ContrapresiónExcepción (la velocidad a la que realiza la solicitud es demasiado alta para que el SDK/servidor pueda soportarla) o TemporaryFailureException (el servidor notifica que está demasiado ocupado y que las peticiones deben retrasarse un poco). Puede que sólo quieras reintentar hasta 4 veces, y esperar un poco antes de hacerlo... Puede que incluso quieras que este retraso crezca entre cada intento (Retroceso exponencial)?

Anteriormente esto requería un poco de conocimiento de Rx para implementarse, pero ya que este es un caso de uso tan común le hemos traído clases de ayuda para hacerlo fácilmente, en la clase com.couchbase.client.java.util.retry paquete.

El ayudante puede producir un Función que puede pasarse directamente a un Observable's reintentarCuando o también puede envolver un operador Observable introduzca uno de reintento.

Para envolver un ObservableUtilice Retry.wrapForRetry(...) métodos estáticos. Éstos le permitirán cubrir requisitos básicos como reintentar durante un número máximo de intentos, describir el tipo de Retraso que quieras entre intentos.

Para casos de uso aún más avanzados, existe la función RetryBuilder (que produce una función que se pasa a Rx's reintentarCuando operador). Este constructor le permite:

• elegir en qué tipo de errores reintentar (ya sea cualquiera(), anyOf(...), allBut(...)).
• elegir cuántas veces reintentar (ya sea una vez() o max(n) veces).
• personalizar el Retraso y en el que Programador para esperar (delay(...) métodos).

He aquí un ejemplo completo que se ajusta al requisito expresado anteriormente:

Actualizaciones de dependencia

En esta versión, RxJava ha pasado a la versión 1.0.9. También hemos actualizado las dependencias internas (que se vuelven a empaquetar, por lo que es transparente para su aplicación) a las últimas versiones de corrección de errores.

Conclusión

Esperamos que disfrute de estas nuevas funciones de la versión 2.2. Como siempre, agradecemos sus comentarios, especialmente sobre la función de mapeo de entidades y su dirección. Así que vaya a jugar con él, y nos dicen lo que piensa en el foros por ejemplo.

Para obtener la versión 2.2-dp, utilice lo siguiente en un pom.xml de Maven (o descargue directamente los jars para núcleo y cliente):

Por supuesto, también errores corregidos en esta vista previa para desarrolladores, que también formará parte de El lanzamiento oficial de la versión 2.1.3 está previsto para la próxima semana..

¡Aún no hemos terminado con la 2.2! Tendremos muchas funciones próximamente, entre ellas más compatibilidad con N1QL, y perfiles y métricas integrados.

¡Feliz codificación!

- El equipo del SDK de Java