Шаблон проектирования - сложное управление версиями MultiObject с отсутствием последовательности

Question

Вот сделка / вызов,

Мы должны отслеживать информацию и ее линейные изменения. Мы также должны отслеживать изменения, которые вышли за пределы последовательности. Например, А произошло тогда, Б случилось. Некоторое время спустя мы узнаем о C, который на самом деле произошел до B. Наряду с этим испытанием у нас есть много объектов, которые должны быть версионированы и привязаны друг к другу. Если бы это была одна таблица / объект, который должен был быть версионирован ... ничего страшного. Но, с несколькими объектами, теперь мы получаем более сложные связи. И, добавление концепции вне последовательности событий просто усложняет вещи.

При проверке кода вы не можете делать это вне последовательности. Вещи случаются, а затем вы исправляете / улучшаете их. Однако в некоторых системах вы не получаете всю информацию во время события или в линейном порядке. Тем не менее, вам все еще необходимо рассчитать временную шкалу реального события, даже если она отличалась от временной шкалы, в которую вы получили информацию.

Краткий пример иерархии: (каждый объект должен быть версионным)

1. Политика
2. Транзакция (Дата реального изменения)
3. Покрытие (я)
4. Местоположение (я)
5. Покрытие (я)
6. Транспортное средство (а)
7. Яда Яда Яда

С точки зрения, если мне нужно получить доступ к текущей политике, я должен видеть все как есть. Однако, если мне нужно увидеть, что было изменено как часть транзакции 3 недели назад, я должен иметь возможность увидеть, что было раньше ... что именно было изменено ... затем то, что было после изменения.

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

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

Answer 1

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

Для простоты мы реализовали обмен на пространство.

Необходимо 5 основных ключей. Основной идентификатор, LinearInstanceID, LinearPreviousID, NonLinearInstanceID и NonLinearPreviousID.

1. ID = так же, как вы ожидаете, уникальный идентификатор для типа объекта
2. NonLinearInstanceID = первый идентификатор первого в истории экземпляра создано за все время
3. LinearInstanceID = первый идентификатор первого экземпляра на конкретном линейная шкала времени
4. NonLinearPreviousID = Id объекта, для которого он принял место
5. LinearPreviousID = Id изменения непосредственно перед ним (т.е. связанный список)

Последняя часть головоломки - это стробирование рабочего процесса, чтобы решить, когда требуется новая версия всего стека прикрепленных объектов. Обычно это легко, поскольку у вас есть естественная транзакция на бизнес-уровне.

События

- все события: создать новые уникальные первичные идентификаторы

1-я версия:

1. установить LinearInstanceId & NonLinearInstanceId = ID
2. оставить оба предыдущих идентификатора пустыми

Новая версия (обычная линейная):

1. копирование последних версий объектов
2. убедитесь, что LinearInstanceId и NonLinearInstanceId остаются такими же, как они были
3. указывает LinearPreviousId на идентификатор версии перед ним
4. NonLinearPreviousId остается нулевым

Новая версия (необычная нелинейная):

1. получить все объекты на текущей новейшей временной шкале и скопировать их
2. указывает NonLinearPreviousId на идентификатор на временной шкале, с которой они были скопированы с
3. обновить LinearInstanceId до идентификатора новой первой копии
4. убедитесь, что NonLinearInstanceId остается прежним
5. вставить новую версию, заново связать цепочку LinearPreviousId (связанный список)

Преимущества

Я знаю, что это похоже на множество ссылок, но вот некоторые из преимуществ:

Легко перемещаться в эти области на текущей временной шкале или по всем временным шкалам

• Оригинальная или текущая версия
• Предыдущая или следующая версия
• Список версий
• Сохранить все версии каждого объекта (работает нормально в традиционной СУБД)
• Может использовать простые методы для обнаружения изменений между версиями, поскольку все версии сохраняются и может легко перемещаться назад / вперед

Надеюсь, это поможет любому, кто находится в такой же ситуации. Если у вас есть какие-либо вопросы / комментарии, дайте мне знать. Если поможет визуальная помощь, просто дайте мне знать.