Стратегия управления версиями CouchDB

Question

Будет ли жизнеспособная стратегия для реализации управления версиями (с использованием «примера» в качестве образца типа документа):

Имейте один оригинальный документ, где поле типа названо example_original.

Все последующие изменения документа имеют тип example_change и идентификатор документа example_original в качестве ключа. Изменение также будет содержать метку времени.

Сохраните один документ с типом example_current, который является результатом example_original со всеми применимыми example_change. Новый документ example_change будет автоматически применен к этому документу.

Поиск конкретной версии будет состоять из извлечения документа example_original и применения желаемых изменений (в основном до определенной временной отметки, но это также может быть ряд изменений).

Я должен упомянуть, что мой вариант использования будет включать ограниченное количество изменений в оригинале. Большинство обновлений будут состоять из новых оригинальных документов. Хотя это мой текущий вариант использования, меня также интересовали бы проблемы, которые могли бы возникнуть, если бы произошло много изменений.

Какие плюсы и минусы вы видите в этом подходе?

Answer 1

Простое управление версиями документов с CouchDB

Описанный в этой статье подход управления версиями как вложений должен соответствовать требованиям большинства пользователей к управлению версиями.

Answer 2

Мое первое беспокойство: при получении определенной версии вы можете применить изменения к оригиналу без изменения базы данных?

Вам когда-нибудь понадобится что-то удалить из истории?Вы действительно уверены?Действительно, действительно уверен?Как насчет филиалов?

В целом, это выглядит как сложная стратегия.Имейте в виду, что я слышал о CouchDB, но никогда не использовал его.Я бы выбрал более простой подход:

1. Когда вы создаете документ, вы назначаете UUID.Не используйте имя, иначе у вас возникнут проблемы при переименовании.Добавьте поле версии, которое гласит «1».Создайте второй документ, который содержит список документов с тем же UUID, или добавьте «родительский» указатель на первый документ.

   Наличие «исторического документа» для каждого документа обеспечивает более быструю навигацию по истории, но родительские указателиявляются более «безопасными» (поскольку вы не можете легко создавать нелегальные структуры с ними). ​​

2. Когда вы создаете новую ревизию, повторно используйте UUID и назначьте новую, уникальную версию.Обновите исторический документ или родительский указатель.

Эта стратегия довольно проста в реализации и обеспечивает гибкость в будущем.Вы можете легко удалять части истории, переименовывать просто и создавать ветки.

Answer 3

Каков бизнес статус этих документов, особенно юридических? Я работал в ситуациях, когда ваше предложение было бы неуместным с точки зрения бизнеса, потому что нужно было доказать, что документ, представленный как v.3, действительно является версией 3 документа. Динамическое применение дельт не уменьшит соответствие требованиям.

Если, как вы говорите, изменения в документах происходят нечасто, вы не собираетесь экономить много места на диске, сохраняя дельты вместо целых документов. Хранение целых документов также позволяет надежно прогнозировать время поиска для любого документа. Это также уменьшает сложность процесса поиска.

Answer 4

Стратегия управления версиями с помощью CouchDB - НЕ сжимать базу данных, содержащую документы, для которых вам необходимо вести полную историю. Вы все еще можете сжать другие базы данных. Эта простая стратегия работает сегодня из коробки со стратегией редактирования разрешения конфликтов.

Удаление документа можно выполнить, написав новую версию без содержимого, но с удаленным набором свойств.

Ветвления не могут быть сделаны таким образом, потому что механизм управления версиями предлагает один поток ревизий.

Теперь о возможном будущем CouchDB:

• Сегодня каждая ревизия содержит полную копию документа, но можно подумать, что оптимизация механизма CouchDB может однажды сохранить дельты.
• Также возможно, что в будущем CouchDB предложит API для предотвращения сжатия определенных типов документов. Это позволило бы хранить все документы в одной базе данных. Это будет простой патч для CouchDB.
• Эта стратегия позволяет управлять ветвями документов, но, учитывая природу CouchDB как базы данных документов, это разумная, но долгосрочная возможность.