Spring Data Couchbase: Uma nova geração (visualização 2.0)

O Dados do Spring Couchbase O projeto comunitário foi historicamente construído sobre a 1.4 geração do oficial SDK Java do Couchbaseembora o SDK 2.0 já foi lançado há algum tempo.

Mas agora é definitivamente um ótimo momento para fazer o upgrade Dados do Spring Couchbase para o SDK 2.2 mais recente, especialmente porque ele é o único com suporte para N1QLtambém conhecido como "SQL for Documents", a nova linguagem de consulta do Couchbase.

A geração do SDK 2.x é uma reescrita completa, construída sobre uma camada totalmente assíncrona e expondo RxJava Observávels para a API assíncrona. Como tal, ele tem um nome de artefato Maven separado e garante uma versão principal do Spring Data Couchbase.

As principais diferenças entre a geração 1.x do Spring Data 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 um cluster!)
• O backup de métodos personalizados nem sempre é feito com visualizações Agora, por padrão, ele é feito via N1QLque é muito mais flexível e exige muito menos manutenção no lado do servidor.
• Métodos personalizados usando visualizações foram um pouco modificados para se adequarem melhor à filosofia do Spring Data. Isso reduz a flexibilidade, mas as implementações são geradas a partir do nome do método ("derivação de consultas“).
• Agora há suporte para a redução de visualização.
• Alterar o nome do campo JSON que armazena informações de tipo ("_classe") agora é suportado. Por exemplo, um Gateway de sincronização-compatível, javaClassé oferecido em MappingCouchbaseConverter.TYPEKEY_SYNCGATEWAY_COMPATIBLE.

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

Vamos nos aprofundar um pouco mais nessas mudanças!

Métodos de repositório por meio do N1QL

O grande novo recurso do Couchbase 4.0 é N1QLum superconjunto do SQL que funciona em documentos JSON (portanto, adicionou especificidades relacionadas ao JSON ao SQL).

Isso é especialmente bom para o padrão Repository e a derivação de consultas no Spring Data, porque a grande maioria das palavras-chave de derivação de consultas também é facilmente traduzida para N1QL.

O N1QL agora é o recurso padrão de apoio do Couchbase para métodos de repositório. Você também pode optar por usar o recurso @Query se você quiser ser explícito.

Por exemplo, um método derivado de consulta usando o N1QL poderia ter a seguinte aparência:

Isso, por sua vez, para os parâmetros "frutas", "cheesecake", 5, nos dá uma consulta N1QL semelhante a:

Como você pode ver, a estrutura até mesmo escolherá corretamente quais campos selecionar (incluindo metadados) para poder desmarcar o documento em um PartyCake entidade.

Quanto às visualizações, primeiroX sintaxe para LIMITE e countBy em vez de findAllBy para fazer um SELECT COUNT(*) também são suportados.

Outra vantagem em relação às exibições é que você pode ter um único índice de propósito geral (um "índice primário" da perspectiva do N1QL) e usá-lo para todas as suas consultas, o que reduz o ajuste do lado do servidor em comparação com as exibições, em que cada consulta diferente precisará de uma exibição diferente.

Observação: é claro que você também pode criar índices secundários mais especializados e eficientes no N1QL.

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 derivação de consultas para as consultas mais simples.

Isso significa que você pode fazer algo assim:

A estrutura pegará essa interface e criará uma consulta com o nome do método e os parâmetros fornecidos. Por exemplo, chamá-lo com um Lista de frutas e açúcar resultará em uma consulta como ?keys=["fruit","sugar"].

Consulte a documentação para obter uma lista exaustiva das palavras-chave no nome do método que podem ser traduzidas para um parâmetro de consulta. Para qualquer outro uso, você deve fornecer a implementação por conta própria.

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

Outra novidade que não era suportada anteriormente é a execução da função reduzir a função se você tiver um. Agora, para executá-lo, basta declarar um método que comece com contagem em vez de findAllque retorna um long.

Observe que a função de redução no Couchbase pode ser outra que não a função preexistente _count desde que retorne um long.

Da mesma forma, adicionar a variação "topX" ou "primeiroX" em um nome de método resultará em um limite sendo definido 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 faz o backup do N1QL), é a necessidade de Leia seus próprios textos.

Isso implica que a exibição/N1QL não deve responder enquanto os dados ainda estiverem em processo de indexação, o que compromete 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 um meio global de configurar isso para 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.

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

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

Por fim, alguns usuários relataram problemas com o Spring Data e o Couchbase Mobile, com o Gateway de sincronização rejeitar documentos que contenham campos prefixados por um sublinhado.

Isso é problemático porque o Spring Data armazena as informações de tipo em um arquivo _classe campo :(

A solução é permitir, por meio da configuração, escolher o nome do campo de informações desse tipo. Você pode fazer isso substituindo a função 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.

Configuração

O SDK 2.0 agora está mais próximo da terminologia de um cluster do Couchbase, com objetos como Aglomerado e Balde como cidadãos de primeira classe. Como resultado, na configuração de dados do Spring, em vez de um Cliente Couchbase você configura feijões mais diversificados.

O ajuste do SDK é feito em uma classe separada, a classe CouchbaseEnvironmentque permite ajustar os pools de io, tempos limite, etc. Os ambientes devem ser reutilizados o máximo possível entre Aglomerados, e Aglomerados devem ser reutilizados para abrir Baldes (tudo deve ser reutilizado o máximo possível, basicamente).

Para obter um CouchbaseTemplateé necessário um Meio ambiente, a Aglomerado e um Balde. Todos eles são criados automaticamente ao estender o JavaConfig AbstractCouchbaseConfigurationA única coisa que você precisa fornecer é:

• a lista de nós para o bootstrap (apenas os IPs ou os nomes de host)
• o nome do balde
• a senha do bucket

É claro que, se você quiser substituir, por exemplo, o padrão Meio ambiente você pode substituir os métodos correspondentes na configuração AbstractCouchbaseConfiguration (conforme mostrado no trecho abaixo):

O equivalente em xml é:

Configuração no lado do servidor

Métodos CRUD do Spring Data Couchbase obtidos de um CrudRepository ainda são apoiadas pelas operações de chave/valor do Couchbase (ao trabalhar com entidades únicas ou entidades mutantes) ou por uma interface visualização (ao trabalhar em várias entidades das quais não sabemos o ID, por exemplo, para count() ou findAll() métodos).

Isso significa que você ainda precisa ter um índice de todas as suas entidades de alguma forma, na forma de uma exibição no Couchbase.

Por padrão, a estrutura procurará o nome da sua entidade, sem letras maiúsculas, para o documento de design e uma exibição chamada todos (por exemplo. partyCake/all para um PartyCake classe de entidade).

Conclusão

Isso é tudo (por enquanto) para esta primeira versão prévia do Spring Data Couchbase 2.0.x. Espero que você goste!

O documentação do projeto e o README foram atualizados com esses novos recursos, e todo o código e a documentação estão visíveis no diretório 2.0.x no ramo Repositório do Github do Spring Data Couchbase.

Agradecemos ao Oliver, da equipe do Spring Data, por seu apoio e aos nossos usuários que participaram e ofereceram contribuições ou sugestões de aprimoramento (não é uma lista exaustiva):

vasilievip, KlausUnger, kdheerendra, jloisel, DWvanGeest, ajbrown, wilsondy

Para fazer o download e usar essa visualização, use Maven (com os dois Primavera instantâneo e Couchbase repositórios de snapshot):