Vista previa utilizando N1QL DP4 desde el SDK de Java

Como algunos ya sabréis, el equipo de Query de Couchbase ha estado trabajando duro en una nueva y emocionante funcionalidad, N1QLque aporta la potencia de los lenguajes de consulta (como SQL) a Couchbase.

Acaban de publicar la Developer Preview 4 de N1QL (véase el entrada del blog aquí), con un montón de mejoras, API REST, etc...

Nos complace anunciar que ya está disponible una Vista Previa para Desarrolladores del SDK de Java compatible con N1QL DP4. La gestión de consultas se ha sometido a una serie de cambios en esta versión, lo que refleja mejor el estado en que estará en 2.1 (momento en el que N1QL también debería obtener la estabilidad de Disponibilidad General).

Cómo obtener el código y utilizar la función

Para obtener N1QL y activarlo, consulte el documentación introductoria¡! Existen varios pasos para activar la indexación N1QL en sus buckets.

ACTUALIZACIÓN: Una segunda vista previa del SDK para desarrolladores ya está disponible, pom y los enlaces de abajo se han actualizado en consecuencia. Desplácese hasta la parte inferior para ver los cambios...

Para obtener el código de esta versión preliminar para desarrolladores, utilice el siguiente fragmento en Maven pom.xml o descargar el core-io y java-client directamente.

Dado que se trata de una función experimental, es necesario activarla explícitamente en el SDK. Esto puede hacerse de dos maneras: pasando -Dcom.couchbase.queryEnabled=true como parámetro de la JVM o utilizando CoreEnvironment al inicializar el Grupo en código:

Para reproducir los ejemplos de este blog (que se construyen unos sobre otros, es decir, copiar todos los fragmentos en una clase Java para obtener un ejemplo completo que funcione.), también puede utilizar el código siguiente para generar dos documentos que puedan consultarse:

¿Qué ha cambiado desde la versión 2.0.3 / N1QL DP3?

A continuación se describen los cambios más notables.

Consulta ha pasado a llamarse Declaración

En N1QL, una consulta completa se compone como mínimo de una Declaración (ej. SELECT * FROM por defecto), pero también pueden tener valores posicionales/nombrados y parámetros de petición adicionales (como tiempos de espera del servidor, consistencia del escaneo, ...).

En Consulta en versiones anteriores sólo representaba este componente de enunciado, por lo que se ha renombrado a Declaración.

Consulta introducción de la jerarquía de clases

Consulta se ha mantenido, pero para representar la consulta N1QL completa. Se ha introducido una jerarquía de clases que representan las consultas desde la más simple (una sola sentencia, SimpleQuery) a otros más avanzados (ParametrizedQuery, PreparedQuery).

Las consultas pueden construirse a través de métodos de fábrica en el módulo Consulta clase abstracta.

Uno puede hacer consultas con sentencias avanzadas no cubiertas por el DSL usando los métodos que toman una Cadena como sentencia, por ejemplo para asegurar que hay un índice N1QL en nuestro cubo objetivo:

Parámetros para sentencias y consultas

DP4 introduce el concepto de sentencias parametrizadas. Estas sentencias tienen marcadores de posición que el servidor puede rellenar introduciendo sus valores en la consulta. Los marcadores de posición se nombran (con el carácter $name ) o posicional (con el formato $1 formato).

Estas consultas se representan mediante un ParametrizedQuerytomando valores en forma de a JsonObject de pares nombre-valor para marcadores de posición con nombre o JsonArray de valores para los marcadores de posición. Nota: Actualmente hay un error en N1QL DP4 que impide que los parámetros con nombre funcionen, utilice parámetros posicionales en su lugar.

Además, Parámetros de consulta describe todos los parámetros de consulta restantes que son compatibles con el SDK: ID de contexto del cliente, tiempos de espera del lado del servidor, consistencias de escaneo. Pueden añadirse a cualquier solicitud utilizando el método ad-hoc Consulta método de fábrica.

Declaraciones preparadas

Otra gran novedad de N1QL DP4 es la introducción de las sentencias preparadas. Dichas sentencias se construyen en dos pasos - analizar la sentencia y producir un plan de consulta. - ejecutar el plan de consulta y devolver los resultados.

El paso de preparación, que devuelve un plan de consulta, puede omitirse tras la primera ocurrencia siempre que el plan haya sido almacenado en caché en algún lugar por el usuario. Esto permite al servidor saltarse un paso, lo que supone una ganancia de tiempo.

A Plan de consulta puede obtenerse del servidor llamando a Bucket.prepare(s), s siendo cualquier Declaración. Este objeto puede almacenarse en caché y reutilizarse varias veces posteriormente.

Para ejecutar un plan, utilice Bucket.query(Query.prepared(plan)). Tenga en cuenta que el preparado también puede aceptar parámetros de consulta y valores de marcador de posición (siempre que la sentencia original tuviera los marcadores de posición correspondientes).

Cambios en el formato de los resultados

DP4 introdujo varios cambios en el formato de la respuesta del servidor, que se han reflejado en el SDK, en AsyncQueryResult (la versión sincrónica Resultado de la consulta presenta cambios similares):

• Los resultados pueden transmitirse al cliente antes de que se haya determinado un estado definitivo (por ejemplo, cuando falla el procesamiento de uno de los resultados o hay advertencias que no se rompen). En este caso, se creará una nueva finalSuccess() se ha introducido el método booleano. éxito() se convierte en parseSuccess()lo que permite al usuario detectar por adelantado un error, pero el verdadero estado final de la consulta sólo puede conocerse al final, esperando a que finalSuccess().
• Los errores pueden ser múltiples y tener distintos niveles. Por ello error() se sustituye por errores()devolviendo un Observable de errores y advertencias.
• info() ya no contiene errores ni advertencias de ningún tipo, sino una emisión única de métricas como temporizadores, número de filas, tamaño de los valores de respuesta, etc...

Obsérvese que la obtención del Resultado de la consulta ahora se bloquea hasta que toda la respuesta está disponible. Hasta ahora, se bloqueaba hasta que se procesaba el primer fragmento de la respuesta, potencialmente antes de que las filas estuvieran disponibles, por lo que este cambio puede introducir un retraso ligeramente mayor en la obtención del resultado (retraso inicial anterior + el producido por una llamada posterior a allRows()).

Cambios en la Developer Preview 2

Esta versión corrige varios errores en las consultas:

• Corrección de un error de análisis cuando la respuesta es demasiado grande y un fragmento sólo está formado por filas de resultados.
• Corrección de un error de bloqueo que provocaba tiempos de espera constantes en las consultas de algunos usuarios.

Además, se han introducido algunos cambios en las funciones:

• Se han añadido accesores para el identificador de petición (generado por el servidor N1QL) y el identificador de contexto del cliente (proporcionado por el usuario al realizar la consulta, pero truncado a 64 bytes de caracteres UTF8 por el servidor).
• Se ha añadido una función de preparación en Bucket que acepta una sentencia String para obtener un QueryPlan para ella.

Gracias a los usuarios de los foros que nos han hecho llegar sus comentarios y problemas.

La versión también contiene varias correcciones de errores y nuevas características no relacionadas con N1QL, que no vamos a detallar aquí (por favor, consulte las notas de la versión de java-client y core-io).

Conclusión

Esperamos que disfrutes de N1QL y de la codificación de peticiones N1QL con el último SDK de Java. Como siempre, damos la bienvenida a comentarios, sugerenciaserror informa (bueno, no es que los disfrutemos hasta el nivel de introducir bichos voluntariamente) e incluso contribuciones :)

¡Feliz codificación!

El equipo del SDK de Java