Couchbase Java SDK 2.2 Developer Preview 1

Em nome da equipe do SDK, tenho o prazer de apresentar a próxima grande versão do Java SDK, o Versão 2.2. A equipe tem trabalhado arduamente para trazer a você novos recursos incríveis, e hoje achamos que é hora de lançar alguma luz sobre eles com o lançamento da primeira visualização para desenvolvedores.

2.2 traz uma série de novos recursos:

• Aprimorado N1QL suporte
• Simples Mapeamento de entidades
• Várias APIs aprimoramentos
• Classes auxiliares para simplificação tentar novamente manuseio
• Versão de saliências de algumas dependências

Ir para o conclusão se não puder esperar para colocar suas mãos no código :)

Alterações relacionadas ao N1QL

Recentemente, foi lançado o Couchbase Server v4.0 Developer Preview. Entre os vários recursos dessa nova versão, a integração de nossa nova linguagem de consulta "SQL for Documents" (codinome N1QL) é um dos principais.

Nas versões anteriores do Java SDK, já tínhamos suporte para o N1QL (especialmente para a 4ª Developer Preview separada que foi lançada pela equipe de consulta no início deste ano), e continuamos dessa forma.

Desde a N1QL DP4, temos ampliou a DSL, adicionou uma DSL para gerenciamento de índices e acrescentou suporte a senhas de balde.

Extensão DSL

Várias partes da DSL foram ampliadas e aprimoradas. Fizemos com que todo o Tutorial N1QL pode ser implementado por meio do Java DSL.

O DE pode fazer referência a IDs de documentos por meio da cláusula USAR CHAVES enquanto outras cláusulas (como JUNTAR ou NEST), por outro lado, referem-se a IDs de documentos por meio de SOBRE AS CHAVES cláusula.
A DSL existente para isso estava apenas produzindo CHAVES o que não é suficiente, então ambas as variantes foram reimplementadas como useKeys/useKeysValues e onKeys/onKeysValues na DSL.

No N1QL, temos o conceito de predicados de coleção (ou compreensões) com os operadores ANY, EVERY, ARRAY e FIRST. Introduzimos uma mini-DSL, Coleçõespara criar esses predicados e produzir um Expressão que os representa, para ser usado no restante da DSL.

Em alguns casos, o N1QL oferece alternativas de sintaxe e padrões. Três deles vêm à mente, pois abordamos ambos de forma um pouco diferente:

• o AS A sintaxe de aliasing pode, às vezes, omitir completamente a palavra-chave, como em FROM default AS src vs DE src padrão. Optamos por produzir apenas a forma explícita com o AS (já que o usuário precisa chamar a palavra-chave as(String alias) de qualquer forma).
• USAR CHAVES e SOBRE AS CHAVES têm sintaxe alternativa opcional CHAVES PRIMÁRIAS DE USUÁRIO e EM CHAVES PRIMÁRIAS. Elas são semanticamente equivalentes e produzimos apenas a primeira forma.
• ORDER BY tem uma direção de pedido padrão em que não se pede explicitamente DESC nem ASC. Implementamos essa opção no Classificar com o operador def(Expressão onWhatToSort) método.

Algumas funções, algumas das quais foram implementadas anteriormente no Funções foram adicionados/movidos para a classe ...query.dsl.functions em classes auxiliares separadas que correspondam à categoria das funções dentro delas (por exemplo. StringFunctions).

Em Expressãoadicionamos alguns métodos de fábrica para construir expressões a partir de um Declaração (como fazer uma subconsulta) e construir um caminho:

Também adicionamos operadores aritméticos adicionar, subtrair, multiplicar e dividir:

Por fim, adicionamos outro mini-DSL para o CASO Declaração. O CASE pode ser usado para produzir resultados alternativos, dependendo de uma condição. Ou a condição é explicitada em cada alternativa QUANDO (a expressão é condicional, e essa forma de CASE é chamada de "caso de pesquisa"), ou a condição é apenas igualdade com um identificador/expressão fornecido no início do CASE (como CASE user.gender WHEN "male" THEN 1). Aqui está um exemplo da DSL em ação:

Gerenciamento de índices DSL

Se você já brincou com o N1QL, sabe que pode criar índices para acelerar significativamente suas consultas. Até agora, a única maneira de criá-los programaticamente era emitir uma instrução String bruta. Agora não é mais assim!

A DSL de gerenciamento de índices oferece suporte para as várias operações relacionadas aos índices, a saber

Criação de um índice:

Criando um primário índice:

Eliminação de índices:

Construir índices que foram adiados na criação:

Observe como a maioria dos identificadores (nomes de índices, espaço de nomes/espaço-chave) são automaticamente escapados por backticks.

Suporte à senha do Bucket

Ao consultar o serviço N1QL, agora enriquecemos automaticamente os cabeçalhos da solicitação com informações de autenticação obtidas do serviço de chamada Baldeque permite consultar um bucket protegido por senha de forma transparente (como já era o caso do Consultas).

Mapeamento de entidades

Esse recurso foi muito solicitado no passado: a capacidade de mapear facilmente um objeto de domínio para um documento do Couchbase e vice-versa.

Começamos a explorar isso Mapeamento de entidades (ou ODM, Mapeamento de documentos de objeto) em 2.2. A abordagem é fornecer uma API semelhante a Balde dedicada à ODM. Essa API é descrita na seção Repositório e é possível obter um repositório de um bucket chamando bucket.repository().

Os métodos na API do repositório lidam com um novo tipo de Documento, o EntidadeDocumento. Ele se atém à semântica do documento que separa os metadados do conteúdo (seu objeto de domínio, neste caso). Espera-se que o objeto de domínio seja anotado (veja abaixo) para que o mapeamento funcione.

EntidadeDocumento pode ser usado para fornecer explicitamente um idpara ser usado como chave primária no Couchbase, mas, ao contrário dos outros Documento com as quais você está acostumado, isso é opcional. Como alternativa, você pode anotar um Cordas em sua classe de domínio com @Id para usá-lo como id do documento. @Id nunca é armazenado no conteúdo JSON no Couchbase...

Somente os atributos marcados com o símbolo @Campo são levadas em consideração e tornadas parte do conteúdo JSON no banco de dados/injetadas de volta no objeto quando obter. Essa anotação também pode conter um alias para o nome do campo:

As limitações atuais (algumas das quais podem ser suspensas no futuro) são:

• @Campo só é suportado em atributos de tipo básico (aqueles que podem ser adicionados a um JsonObject) e, em geral, esse ODM é para casos simples. O suporte a mapas, listas e conversores personalizados está sendo desenvolvido.
• somente classes com construtores de argumento zero são compatíveis com o ODM.
• O mapeamento é feito por meio de reflexão para obter/definir os valores dos atributos na primeira vez (depois, ele é armazenado em cache internamente).

Aprimoramentos na API

O existente Balde A API recebeu alguns aprimoramentos.

Em primeiro lugar, foi introduzida uma nova operação para verificar facilmente a existência de uma chave sem pagar o custo de realmente obtero conteúdo do documento. Esse é o exist(String key) método:

Em segundo lugar, um recurso relacionado a visualizações que estava presente na geração 1.x do SDK, mas não na 2.x, é a capacidade de solicitar uma obtenção em massa dos documentos ao fazer uma consulta de visualização (a função includeDocs opção).

Isso não é realmente difícil de fazer na versão 2.x ao usar o assíncrono API (usando o padrão em massa que se baseia no RxJava), mas não existe quando se usa a API de sincronização. De fato, a única maneira de obter o documento correspondente de cada linha no modo de sincronização é chamar row.document()que bloqueará e disparará uma solicitação por linha, em série. Isso é muito ineficiente!

Portanto, reintroduzimos o includeDocs na API de consulta de exibição. Isso acionará o carregamento assíncrono eficiente do documento de cada linha em segundo plano, do qual a API de bloqueio também se beneficia (as linhas já terão o Documento armazenado em cache ao chamar document() nelas). Você também pode usá-lo na API assíncrona, mas lá ele é mais ou menos um "noop" quando você chama .document() no AsyncViewRow.

Auxiliar de repetição

Na verdade, isso é algo que fazia parte do lançamento 2.1.2mas merece ser mencionada em uma postagem de blog.

Um dos benefícios de usar RxJava é que você pode compor operadores Rx de forma significativa e se beneficiar de primitivos avançados de tratamento de erros. Entre eles está o tentar novamente e retryWhen que permitem tentar novamente um fluxo assíncrono em várias condições.

Por exemplo, talvez você queira tentar novamente uma obter ao receber BackpressureException (a taxa de solicitação é muito alta para que o SDK/servidor possa lidar com ela) ou TemporaryFailureException (o servidor notificou que estava muito ocupado e que as solicitações deveriam ser atrasadas um pouco). Você pode querer tentar novamente até 4 vezes e esperar um pouco antes de fazer isso... Talvez você até queira que esse atraso aumente entre cada tentativa (Backoff exponencial)?

Anteriormente, isso exigia um pouco de conhecimento de Rx para ser implementado, mas como esse é um caso de uso muito comum, trouxemos classes auxiliares para fazer isso facilmente, na classe com.couchbase.client.java.util.retry pacote.

O auxiliar pode produzir um Função que pode ser passado diretamente para um Observável's retryWhen ou também pode envolver um operador Observável introduzir uma nova tentativa.

Para embrulhar um Observável, use Retry.wrapForRetry(...) métodos estáticos. Eles permitirão que você atenda aos requisitos básicos, como tentar novamente por um número máximo de tentativas, descrevendo o tipo de Atraso que você deseja entre as tentativas.

Para casos de uso ainda mais avançados, há o Criador de novas tentativas (que produz uma função a ser passada para a função retryWhen operador). Esse construtor permite que você:

• escolher em que tipo de erros tentar novamente (ou qualquer(), anyOf(...), allBut(...)).
• escolher quantas vezes tentar novamente (ou uma vez() ou max(n) vezes).
• personalizar o Atraso e no qual Agendador para esperar (atraso(...) métodos).

Aqui está um exemplo completo que corresponde ao requisito expresso acima:

Atualizações de dependências

Nesta versão, RxJava foi atualizado para a versão 1.0.9. Também atualizamos as dependências internas (que são reempacotadas, de modo que é transparente para o seu aplicativo) para as versões mais recentes de correção de bugs.

Conclusão

Esperamos que você aproveite esses novos recursos da versão 2.2. Como sempre, agradecemos seu feedback, especialmente sobre o recurso e a direção do Mapeamento de entidades. Portanto, brinque com ele e diga-nos o que achou na seção fóruns por exemplo!

Para obter o 2.2-dp, use o seguinte em um Maven pom.xml (ou baixe diretamente os jars para núcleo e cliente):

É claro que também Erros corrigidos nesta visualização para desenvolvedores, que também fará parte do Lançamento oficial do 2.1.3 programado para a próxima semana.

Ainda não terminamos a versão 2.2! Teremos muitos recursos em breve, incluindo mais Suporte a N1QL e perfil e métricas incorporados.

Boa codificação!

- A equipe do Java SDK