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

Question

Будет ли следующее жизнеспособной стратегией для внедрения управления версиями (используя "example" в качестве образца типа документа):

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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