Управление версиями доменной модели - PullRequest
Новая
       11

Управление версиями доменной модели

2 голосов
/ 02 августа 2011

Я реализую управление версиями для моей собственной модели домена (отслеживание различий в объектах во время операций обновления).Доменная модель имеет древовидную структуру.Например ( -> является ссылкой) 

A
|-> B
|-> C -> A
    | -> C

Требования для управления версиями следующие:

  • Получить набор измененных полей между двумя версиями объекта домена;
  • Доменная модель имеет древовидную структуру;
  • Поля могут быть организованы в списки.В следующем примере система должна показать, что элемент Y был удален (но не то, что Z был удален, а Y изменил свое состояние на Z) и X был изменен: 

      [ v1 ]              [ v2 ]
        A                    A
        |-> [X, Y, Z]        |-> [X, Z]
             |-> C                |-> M
  • Больше неттребования, такие как блокировка / слияние / ветвление.

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

Я буду рад получить любые теоретические или практические советы с вашей стороны.

Спасибо

Ответы [ 2 ]

1 голос
/ 02 августа 2011

Я подозреваю, что ваша доменная модель представлена ​​не в текстовых файлах, а как объектная модель, скорее всего, сохраняется в реляционной базе данных. Мы сейчас разрабатываем только это и уже создали его прототип.

Извлеченные уроки:

  1. Вам необходимо точное описание того, какие функции вам нужны для контроля версий, а какие вам не нужны. Просто зарегистрировать изменения легко, обеспечить тегированные версии и ветки с эксклюзивной блокировкой сложно, а объединение - очень сложно.
  2. Регистрация может быть реализована на уровне БД с использованием триггеров. Создайте таблицы для всех объектов вашего домена и, если запись добавлена ​​/ отредактирована / удалена, запишите всю запись. Добавить информацию (время ...) по мере необходимости. Может потребоваться, чтобы каждый пользователь входил в базу данных как собственный пользователь базы данных, чтобы вы могли запросить CURRENT_USER, чтобы зарегистрировать его.
  3. Вместо регистрации до / после изменения изменений вы можете регистрировать изменения атрибутов. Но это создаст намного больше записей в журнале, и это будет дорогостоящим, чтобы собрать все изменения для определенного коммита.
  4. Блокировка объектов может быть выполнена с помощью вызовов методов (блокировка / разблокировка). Проверка на блокировки может быть выполнена на уровне БД с использованием триггеров снова (получите CURRENT_USER и проверьте, заблокировал ли он объект). Это имеет то преимущество, что пользовательский код не должен запрашивать, заблокирован ли объект, но база данных будет препятствовать вставке / редактированию / удалению. Если вы не используете блокировку, вам потребуется реализовать слияние. Это будет очень сложно, так как вы работаете не с текстовыми файлами, а с сильно структурированными данными.
  5. Включение управления версиями в модель вашего домена может быть на удивление хитрым. Особенно, если вам требуется не допустить утечки версий в модель вашего домена (если вы планируете повторно использовать систему контроля версий). Прототип это!
0 голосов
/ 02 августа 2011

Ну, я бы сказал, вы говорите здесь о 2 разных вещах.

У Subversion есть номер ревизии для complete дерева, то есть каждое изменение является дешевой копией предыдущей версии,Таким образом, в вашей иерархии объектов нет изменений.Это больше сумма всех изменений - и они рассчитываются для каждого файла с помощью вашего обычного механизма сравнения.

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

...