Visualização usando o N1QL DP4 do Java SDK

Como alguns de vocês devem saber, a equipe de consulta do Couchbase tem trabalhado arduamente em um recurso novo e interessante, N1QLque traz o poder das linguagens de consulta (como SQL) para o Couchbase.

Eles acabaram de lançar o Developer Preview 4 do N1QL (consulte a postagem no blog aqui), com uma série de melhorias, APIs REST, etc...

Temos o prazer de anunciar que já está disponível uma Developer Preview do Java SDK compatível com o N1QL DP4. O gerenciamento de consultas passou por uma série de alterações nesta versão, que reflete melhor o estado em que estará na versão 2.1 (quando o N1QL também deverá ganhar estabilidade de disponibilidade geral).

Como obter o código e usar o recurso

Para obter o N1QL e ativá-lo, consulte o documentação de introdução! Existem etapas específicas para ativar a indexação N1QL em seus buckets.

ATUALIZAÇÃO: Uma segunda prévia do SDK para desenvolvedores foi lançada, o pom e os links abaixo foram atualizados de acordo. Role até o final para ver as alterações...

Para obter o código para essa Developer Preview, use o seguinte snippet em seu Maven pom.xml ou faça o download do núcleo-io e cliente java jarros diretamente.

Como esse é um recurso experimental, você precisa ativá-lo explicitamente no SDK. Isso pode ser feito de duas maneiras: passando -Dcom.couchbase.queryEnabled=true como um parâmetro da JVM ou usando Ambiente principal ao inicializar o Aglomerado em código:

Para reproduzir os exemplos deste blog (que se baseiam uns nos outros, ou seja, copie todos os trechos em uma classe Java para obter um exemplo funcional completo), você também pode usar o código abaixo para gerar dois documentos que podem ser consultados:

O que mudou desde a versão 2.0.3 / N1QL DP3?

As alterações mais notáveis estão descritas abaixo.

Consulta interface renomeada para Declaração

No N1QL, uma consulta completa é composta, no mínimo, de uma Declaração (por exemplo. SELECT * FROM default), mas também pode ter valores posicionais/nomeados e parâmetros de solicitação adicionais (como tempos limite do lado do servidor, consistência da varredura, etc.).

O Consulta nas versões anteriores representava apenas esse componente de declaração e, portanto, foi renomeada para Declaração.

Consulta hierarquia de classes introduzida

Consulta foi de fato mantido, mas para representar a consulta N1QL inteira. Uma hierarquia de classes foi introduzida, representando consultas desde as mais simples (uma única instrução, SimplesQuery) a outros mais avançados (Consulta Parametrizada, Consulta Preparada).

As consultas podem ser criadas por meio de métodos de fábrica no Consulta classe abstrata.

É possível emitir consultas com instruções avançadas não cobertas pela DSL usando os métodos que recebem uma String como instrução, por exemplo, para garantir que haja um índice N1QL em nosso bucket de destino:

Parâmetros para declarações e consultas

O DP4 introduz o conceito de declarações parametrizadas. Essas declarações têm espaços reservados que podem ser preenchidos pelo servidor passando seus valores na consulta. Os espaços reservados são nomeados (com a tag $name ) ou posicional (com o formato $1 formato).

Essas consultas são representadas por um Consulta Parametrizadaassumindo valores na forma de a JsonObject de pares nome-valor para placeholders nomeados ou JsonArray de valores para placeholders posicionais. Observação: Atualmente, há um bug no N1QL DP4 que impede que os parâmetros nomeados funcionem; em vez disso, use parâmetros posicionais.

Além disso, QueryParams descreve todos os parâmetros de consulta restantes que são compatíveis com o SDK: ID de contexto do cliente, tempos limite do lado do servidor, consistências de varredura. Eles podem ser adicionados a qualquer solicitação usando a função ad-hoc Consulta método de fábrica.

Declarações preparadas

Outro grande recurso novo do N1QL DP4 é a introdução de instruções preparadas. Esses comandos são criados em duas etapas: - analisar a instrução e produzir um plano de consulta. - executar o plano de consulta e retornar os resultados.

A etapa de preparação, que retorna um plano de consulta, pode ser ignorada após a primeira ocorrência, desde que o plano tenha sido armazenado em cache em algum lugar pelo usuário. Isso permite que o servidor pule uma etapa, o que representa um ganho de tempo.

A Plano de consulta pode ser obtido do servidor chamando Bucket.prepare(s), s sendo qualquer Declaração. Esse objeto pode ser armazenado em cache e reutilizado várias vezes posteriormente.

Para executar um plano, use Bucket.query(Query.prepared(plan)). Observe que o preparado O método de fábrica também pode aceitar parâmetros de consulta e valores de espaço reservado (desde que a declaração original tenha os espaços reservados correspondentes).

Alterações no formato dos resultados

O DP4 introduziu várias alterações no formato da resposta do servidor, que foram refletidas no SDK, em Resultado de consulta assíncrona (a versão síncrona Resultado da consulta tem alterações semelhantes):

• Os resultados podem ser transmitidos para o cliente antes que um status definitivo seja determinado (por exemplo, quando o processamento de um dos resultados falha ou quando há avisos não quebráveis). Dessa forma, um novo finalSuccess() foi introduzido. sucesso() torna-se parseSuccess()permitindo que o usuário detecte um erro antecipadamente, mas o status final real da consulta só pode ser conhecido no final, aguardando finalSuccess().
• Os erros podem ser múltiplos e ter níveis diferentes. Dessa forma erro() é substituído por erros(), retornando um Observável de erros e avisos.
• info() não contém mais erros ou avisos em nenhuma capacidade, mas sim uma emissão única de métricas como temporizadores, número de linhas, tamanho dos valores de resposta, etc...

Observe que a obtenção do Resultado da consulta agora bloqueia até que toda a resposta esteja disponível. Até agora, ele bloqueava até que a primeira parte da resposta fosse processada, possivelmente antes que as linhas estivessem disponíveis, portanto, essa alteração pode introduzir um atraso um pouco maior na obtenção do resultado (atraso inicial anterior + aquele incorrido por uma chamada subsequente para allRows()).

Alterações no Developer Preview 2

Esta versão corrige vários erros de consulta:

• Corrige um erro de análise quando a resposta é muito grande e uma parte é composta apenas de linhas de resultado.
• Correção de um erro de bloqueio que leva a tempos limite constantes ao fazer consultas para alguns usuários.

Além disso, algumas alterações também foram feitas em termos de recursos:

• Adicionados acessores para o ID da solicitação (gerado pelo servidor N1QL) e o ID do contexto do cliente (fornecido pelo usuário ao fazer a consulta, mas truncado em 64 bytes de caracteres UTF8 pelo servidor).
• Adição de uma substituição de preparação no Bucket que aceita uma instrução String para obter um QueryPlan para ele.

Agradecemos aos nossos usuários nos fóruns que forneceram feedback e sinalizaram problemas!

A versão também contém várias correções de bugs e novos recursos não relacionados ao N1QL, que não detalharemos aqui (consulte as notas de versão do cliente java e núcleo-io).

Conclusão

Esperamos que você goste do N1QL e da codificação de solicitações N1QL com o Java SDK mais recente. Como sempre, damos as boas-vindas a feedback, sugestões, bug relatórios (bem, não que gostemos deles a ponto de introduzir bugs voluntariamente) e até mesmo contribuições :)

Boa codificação!

A equipe do Java SDK