Anunciando o lançamento do Spring Data Couchbase 2.0

O Spring Data Couchbase 2.0 é uma reescrita do conector original do Spring Data Couchbase 1.4.x. Ele é baseado no Couchbase Java 2.2 SDK e faz uso intenso da nova linguagem de consulta N1QL (que foi introduzida no Couchbase Server 4.0) para oferecer mais recursos aos usuários do Spring Data.

O Primeiro marco foi lançado em agosto do ano passado, seguido de um Release Candidate e, desde então, recursos adicionais (e correções de bugs) foram implementados, e agora a versão GA pode ser liberada para o público.

Vamos fazer um rápido tour pelo que mudou (com uma notação de ⭐ a ⭐⭐⭐⭐ de quão incrível e significativo achamos que cada recurso é?)

Novos recursos no Spring Data Couchbase 2.0

As principais diferenças entre a geração 1.x do Dados do Spring Couchbase e sua versão 2.x são:

• Os elementos de configuração estão mais próximos da realidade do Couchbase: Ambiente, Cluster, Bucket (potencialmente permitindo que você crie CouchbaseTemplates que se conectam a um bucket diferente, ou até mesmo a clusters diferentes!)
• O backup de métodos de repositório personalizados nem sempre é mais feito com exibições; agora é (por padrão) feito por meio do N1QL, que é muito mais flexível e exige menos manutenção no lado do servidor.
• Os métodos personalizados que usam exibições foram um pouco modificados para se adequarem melhor à filosofia do Spring Data. Isso reduz um pouco a flexibilidade, mas as implementações são geradas a partir do nome do método (por meio de "derivação de consulta").
• Agora, você pode fazer consultas geoespaciais de seus dados (ou consultas multidimensionais, se for além de 3 dimensões) com visualizações.

É claro que você ainda pode acessar a API de nível inferior usando o CouchbaseTemplate em vez de CouchbaseRepository e você pode até mesmo acessar a interface subjacente Balde do SDK.

Métodos de repositório por meio do N1QL

⭐⭐⭐

O grande novo recurso do Couchbase 4.0 é N1QLuma extensão SQL que funciona em documentos JSON (portanto, adicionou especificidades relacionadas ao JSON ao SQL).

Isso é especialmente bom para o Repositório padrão e derivação de consultas no Spring Data, porque a grande maioria das palavras-chave de derivação de consultas pode ser facilmente traduzida para N1QL.

O N1QL agora é o recurso padrão de apoio do Couchbase para os métodos do Repositório. Você também pode optar por usar a interface @Query se quiser ser explícito na consulta executada.

Métodos de repositório por meio de visualizações

⭐⭐

Uma grande mudança nesta versão é que, agora, as consultas de repositório (também conhecidas como métodos de repositório personalizados) baseadas em exibições estão mais alinhadas com a filosofia do Spring Data. Elas também precisam ser anotadas explicitamente com @View(viewName="something").

Isso significa que nada específico do Couchbase deve vazar para a interface do seu repositório. Em vez disso, o que você pode fazer é usar mecanismos de derivação de consultas para a maioria das consultas.

A derivação de consultas também é possível em pequena escala, com algumas palavras-chave sendo aceitas em um método apoiado em visualização.

Usando a função reduce das visualizações

⭐

Outra novidade que não era suportada anteriormente é a execução da função de redução, se você tiver uma. Agora, para executá-la, basta definir o parâmetro reduzir para true no sinalizador @Ver anotação.

Você também pode prefixar seu método com "count" em vez de "find" se isso for significativo para você (ou seja, se você realmente usar a função de redução "count").

Observe que a função reduce no Couchbase pode ser algo diferente da função _count preexistente e pode até mesmo retornar algo diferente de um long, como um JsonObject, como no caso do built-in _estatísticas.

Da mesma forma, adicionar a variação "topX" ou "firstX" em um nome de método resultará na definição de um limite adicional na solicitação (por exemplo. findFirst5ByLastName limitará a lista a 5 resultados).

Configurando a consistência, leia seus próprios textos

⭐⭐⭐

Um aspecto que surge com frequência ao usar índices secundários preenchidos de forma assíncrona, como exibições e GSI (o novo mecanismo de índice secundário que dá suporte ao N1QL), é a necessidade de ler imediatamente as modificações de suas operações de gravação anteriores.

Isso implica que a exibição/N1QL não deve responder enquanto os dados ainda estiverem em processo de indexação, o que sacrifica um pouco o desempenho em favor da consistência.

O oposto (e o padrão atual do Spring Data Couchbase) é favorecer o desempenho aceitando o retorno de dados obsoletos.

Adicionamos uma semântica global para configurar todas as consultas (baseadas em visualização ou em N1QL) que são construídas pela estrutura por meio da derivação de consultas, fornecendo uma pequena abstração em torno do conceito de consistência.

Isso é feito substituindo o AbstractCouchbaseConfiguration's getDefaultConsistency() método. Consistência é um enum que permite que você escolha entre LER_SUAS_PRÓPRIAS_ESCRITAS, FORTEMENTE_CONSISTENTE, UPDATE_AFTER e EVENTUALMENTE_CONSISTENTE. Consulte a documentação oficial para obter mais informações sobre como eles funcionam exatamente e qual é o impacto deles no momento da consulta.

Você também pode fazer isso em XML usando o atributo de consistência no tag.

Desde o GA, os métodos CRUD nos repositórios agora também levam em conta a consistência configurada por padrão.

Alteração do campo de informações de tipo no JSON armazenado

⭐

Alguns usuários relataram problemas com o Spring Data e o Couchbase Mobile, com o Sync Gateway rejeitando documentos que contêm campos prefixados por um sublinhado.

Isso é problemático para o Spring Data, pois, por padrão, ele armazena as informações de tipo em um _classe campo :(

A solução é permitir, por meio da configuração, modificar o nome do campo de informações desse tipo. Você pode fazer isso substituindo o campo typeKey() método em AbstractCouchbaseConfiguration. Por exemplo, você pode usar a constante MappingCouchbaseConverter.TYPEKEY_SYNCGATEWAY_COMPATIBLE (que é "javaClass“).

Esse campo é usado pelas consultas N1QL geradas para filtrar apenas os documentos correspondentes à entidade do repositório.

Suporte para Paginável/Solicitação de página em consultas derivadas do N1QL

⭐⭐

Usando o N1QL, para consultas geradas por meio da derivação de consultas, Paginável e Classificar agora são compatíveis.

• Suporte para PagingAndSortingRepository (Repositório de paginação e classificação) com base no N1QL.
• Adiciona dois findAll métodos que dependem do N1QL para paginação e/ou classificação. Usa a consistência configurada padrão.

Consultas geoespaciais e multidimensionais usando visualizações espaciais

⭐⭐⭐

Consultar o Couchbase usando coordenadas! Desde que sua entidade tenha um Ponto (ou x e y), você pode encontrá-lo usando:

• uma caixa delimitadora: findByLocationWithin(Box area)
• um círculo: findByLocationWithin(Circle area), findByLocationWithin(Point center, Distance radius).
• um polígono: findByLocationWithin(Polygon area), findByLocationWithin(Point[] polygon).
• uma distância findByLocationNear(Point near, Distance maxDistance).

As consultas de círculos e polígonos são realizadas rapidamente como aproximações de caixas delimitadoras no servidor e, em seguida, os falsos positivos são eliminados pela estrutura antes de apresentar os resultados.

Você pode aproveitar o aspecto multidimensional do Couchbase Spatial Views para adicionar dimensões extras às suas consultas (por exemplo, lojas que abrem tarde da noite em uma cidade...).

Observação: se quiser reutilizar anotações, você também pode fazer isso (funciona para @Ver e @Query também):

Em linha N1QL @Query agora tem suporte para SpEL

⭐⭐⭐

As consultas em linha podem usar a notação SpEL para:

1. garantir que a seleção e a filtragem corretas sejam aplicadas à declaração para construir e retornar entidades: use #{#n1ql.selectEntity} para gerar um SELECT ... FROM ... cláusula e #{#n1ql.filter} no ONDE para limitar a consulta à entidade correta.
2. computam valores ou recuperam dados de valores externos do SpEL configurados no contexto do Spring.

A criação dos índices "principais" do repositório pode ser acionada automaticamente

⭐⭐

⚠️ IMPORTANTE: isso é considerado um auxílio durante o desenvolvimento/testes e não é recomendado na produção

Para garantir que a indexação N1QL das entidades em um determinado repositório seja ativada em um ambiente de desenvolvimento ou pré-produção, é possível anotá-lo com @N1qlPrimaryIndexed (que permite a consulta de forma livre em todo o balde) e @N1qlSecondaryIndexed (que indexará apenas os documentos correspondentes ao tipo de entidade, de forma semelhante à cláusula WHERE produzida pelo SpEL #{#n1ql.filter}).

Além disso, a visualização de apoio para a operação CRUD pode ser criada automaticamente ao anotar o repositório com @ViewIndexed (você precisará fornecer o nome do documento de design, que deve corresponder ao nome da classe simples da entidade com a primeira letra em minúscula).

Além disso, esse recurso deve ser ativado por meio da redefinição da opção gerenciador de índice feijão no AbstractCouchbaseConfiguration.

Tipos de retorno simples (primitivos e Cordas) agora são suportados ao usar uma projeção de linha única

⭐⭐

Isso é especialmente voltado para consultas N1QL em linha com funções de agregação como COUNT(*), AVG(campo)etc... A consulta deve retornar uma única linha com uma única projeção.

Suporte a parâmetros nomeados em consultas em linha do N1QL

⭐⭐

Use parâmetros nomeados ou parâmetros posicionais, mas não ambos. A sintaxe para parâmetros nomeados é $paramNameexigindo que cada parâmetro do método seja anotado com @Param("paramName").

Outros recursos

⭐

Outros recursos incluem:

• Corrigir a nomenclatura de beans para que todos os beans criados pelo Spring Data Couchbase sejam prefixados com "couchbase", a fim de evitar conflitos com outras lojas.
• Agora, há suporte para a alteração da classe base de todos os repositórios (seguindo o processo documentado na documentação comum do Spring Data)
• Caso os índices estejam desatualizados, os documentos excluídos são eliminados dos métodos de localização no CouchbaseTemplate
• A expiração pode ser definida em um @Documento, como um longo + timeUnit

Algumas correções de bugs e melhorias em relação ao RC1 também foram implementadas.

Documentação

⭐⭐⭐

Documentação também foi aprimorado, adicionando exemplos orientados para o Couchbase sobre como adicionar a implementação de um método personalizado a um repositório, como alterar a classe base de todos os repositórios, como lidar com SpEL em consultas em linha, ...

Uma observação sobre o Spring Cache

O Spring Cache foi movido para fora do repositório do Spring Data. Ele ainda está lá e planejamos aprimorá-lo. Por enquanto, você pode encontrá-lo em um Couchbase repositório no github, mas em breve ele deverá se reintegrar à família oficial de projetos do Spring.

Obtendo o Spring Data Couchbase

Você pode adicionar o seguinte à seção pom.xml para obter essa versão do GA (no dependências seção:

Esperamos que você goste dessa versão e de todos os novos recursos que ela traz para a mesa. A próxima etapa será a reinserção no Funil trem de lançamento com uma versão 2.1 esperado antes do verão.