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

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

21
задан APC 26 August 2009 в 11:46
поделиться

4 ответа

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

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

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

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

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

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

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

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

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

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

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

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

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

    9
    ответ дан 29 November 2019 в 21:28
    поделиться

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

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

    1
    ответ дан 29 November 2019 в 21:28
    поделиться

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

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

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

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

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

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

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

    19
    ответ дан 29 November 2019 в 21:28
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: