Estratégia de versão do CouchDB

Question

A seguir, seria uma estratégia viável para implementar o versão (usando "Exemplo" como um tipo de documento de amostra):

Tenha um documento original em que o campo de tipo é nomeado Exemplo_original.

Alterações subsequentes no documento têm todos os tipos exemplo_change e o id do documento do exemplo_original como uma chave. A mudança também carregaria um registro de data e hora.

Mantenha um documento com tipo exemplo_current que é o resultado de exemplo_original com todos os exemplos_change "aplicados". Um novo documento do exemplo_change seria aplicado automaticamente a este documento.

Encontrar uma versão específica consistiria em recuperar o DOC Exemplike_original e aplicar as alterações desejadas (principalmente até um certo registro de data e hora, mas também pode ser várias alterações).

Devo mencionar que meu caso de uso envolverá um número limitado de alterações no original. A maioria das atualizações consistirá em novos documentos originais. Embora este seja o meu caso de uso atual, eu também estaria interessado em questões que resultariam se muitas alterações envolvidas.

Que prós e contras você vê nessa abordagem?

Answer 1

Minha primeira preocupação é: ao "obter" uma determinada versão, você pode aplicar as alterações no original sem modificar o banco de dados?

Você precisará excluir algo da história? Você tem certeza? Realmente, muito certo? Que tal galhos?

Em suma, isso parece uma estratégia complexa. Lembre -se de que ouvi falar do CouchDB, mas nunca o usei. Eu iria para uma abordagem mais simples:

1. Ao criar um documento, você atribui um UUID. Não use o nome ou você terá problemas durante as operações de renomeação. Adicione um campo de versão que diz "1". Crie um segundo documento que contém uma lista de documentos com o mesmo UUID ou adicione um ponteiro "pai" ao primeiro documento.

   Ter um "documento de história" por documento permite uma navegação mais rápida da história, mas os indicadores dos pais são mais "seguros" (já que você não pode criar facilmente estruturas ilegais com eles).

2. Ao criar uma nova revisão, reutilize o UUID e atribua uma versão nova e única. Atualize o documento do histórico ou o ponteiro pai.

Essa estratégia é bastante simples de implementar e permite todos os tipos de flexibilidade posteriormente. Você pode apagar partes da história com facilidade, renomear é simples e você pode criar ramificações.

Answer 2

Versão simples de documentos com CouchDB

A abordagem de versão como anexos descrita neste artigo deve ser adequada aos requisitos da maioria das pessoas para versões.

Answer 3

Qual é o status comercial desses documentos, especialmente legal? Eu trabalhei em situações em que sua proposta não seria apropriada de um negócio de negócios, devido à necessidade de provar que o documento apresentado como V.3 é realmente a versão 3 do documento. A aplicação dinamicamente de deltas não cortaria a mostarda de conformidade.

Se, como você diz, alterações nos documentos AE pouco, você não economizará muito espaço em disco, armazenando deltas em vez de documentos inteiros. O armazenamento de documentos inteiros também permite a previsão confiável do tempo de recuperação para qualquer documento. Também reduz a complexidade do processo de recuperação.

Answer 4

Uma estratégia para versões com o CouchDB é nunca compactar o banco de dados que contém os documentos para os quais você precisa manter um histórico completo. Você ainda pode compactar outros bancos de dados. Essa estratégia simples funciona hoje fora da caixa com uma estratégia de resolução de conflitos de edição.

A exclusão de um documento pode ser feita escrevendo uma nova versão sem conteúdo, mas um conjunto de propriedades excluído.

As filiais não podem ser feitas dessa maneira, porque o mecanismo de versão oferece um único tópico de revisões.

Agora, para o possível futuro do CouchDB:

• Hoje, cada revisão contém uma cópia completa do documento, mas pode -se pensar que otimizações do mecanismo CouchDB poderiam um dia armazenar deltas.
• Também é possível que, no futuro, o CouchDB ofereça uma API para impedir a compactação de determinados tipos de documentos. Isso permitiria manter todos os documentos no mesmo banco de dados. Este seria um patch fácil para o CouchDB.
• Essa estratégia permite o gerenciamento de ramificações de documentos, mas considerando a natureza do CouchDB como um banco de dados de documentos, isso é uma possibilidade razoável, mas a longo prazo.