Как правильно версионировать входные данные?

Question

[Касболат Кумахов]

Есть система из нескольких модулей. Основная задача - получить набор XML файлов, проверить их и загрузить в базу.

Последовательность такая:

• Получаем XML
  
• Проверяем по XSD
  
• Проверяем каждую ноду набором скриптов
  
• Сериализуем и загружаем в базу
  

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

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

Какие есть best practises на эту тему?
В СУБД всегда должна быть только последняя версия схемы, но все данные за все время. Хранить предыдущие схемы нет надобности, а данные надо каждый раз адаптировать.
Совместимость нужна только между новой и предыдущей версией файлов. Старьё тянуть не надо.
Изменения могут быть очень глобальными и скрипты могут сильно отличаться.
Как такое лучше реализовать?

Основной затык для меня - это скрипты. Ничего лучше чем вписать в каждый скрипт поддержку версий не придумал.
Но это сильно все усложняет.

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

В общем хотелось бы узнать, кто как решает такую задачу.

UPDATE_1:
Пример:
XML_VER_1.0:

• FIELD_1: 10
  
• FIELD_2: 20
  
• FIELD_3: 30
  

XML_VER_2.0:

• FIELD_3: 30
  
• FIELD_4: 40
  

Вот приходит два таких XML. В базе в результате должно быть записано так:
Первая запись:

• FIELD_1: 10
  
• FIELD_2: 20
  
• FIELD_3: 30
  
• FIELD_4: 0
  

Вторая запись:

• FIELD_1: 0
  
• FIELD_2: 0
  
• FIELD_3: 30
  
• FIELD_4: 40
  

Answer 1

[d-stream]

А если вынести версионную трансформацию в позицию "до"?

То есть отдельно трансформировать прошлую версию в текущую и дальше уже идти по текущему пути. Естественно это приемлемо если есть однозначные трансформации из версии в версию (возможно с хинтами дефотных новых значений и т.п.)

Comments

[Касболат Кумахов]

В новой версии может не быть каких-то полей, а в старой они есть и должны пройти валидацию и сохраниться в базу. Либо же какие-то из полей поменяют свою иерархию. Такое уже наблюдается.

[d-stream]

Касболат Кумахов, то есть однозначной трансформации между Ver.xx и Ver.xx+1 нет???

[Касболат Кумахов]

Может я не так понял?
К примеру есть версия 1.1 и 1.2.
В версии 1.1 есть поле OLD_FIELD. В версии 1.2 такого поля нет.
По вашей идее (если я верно ее понял) мы делаем обработчики только для версии 1.2, а версию 1.1 приводим к 1.2 и просто шлем по пайплайну, верно? Как тогда быть с полем OLD_FIELD?

[d-stream]

Касболат Кумахов, ну общая идея именно такая.
Просто ведь версия 1.2 если нет old_field - и знать о нем не знает и оно ему нафиг не нужно.
Соответственно варианта развития событий два - либо тупо пропускать это поле по причине его бессмысленности, либо в новой версии вместо old_field есть новые поля и тогда трансформация должна что-то вычислить...

[Касболат Кумахов]

Нет. Не пойдет.
OLD_FIELD на момент старой версии было актуально и в базе должно присутствовать, т.к. там вся история.
Это потом оно не нужно, но в какое-то время было необходимо и при всяких отчетах должно быть на этот период. А дальше уже просто будет либо null либо какое-то дефолтное.
Таким образом придется раздувать версию 1.2 старыми полями.

[d-stream]

Касболат Кумахов, стоп-стоп!

есть некая выгрузка в xml, точнее несколько разных версий (например две - старая и новая)

импорт новой версии - ведь подразумевает, что устаревшее поле уже не нужно или его вообще нет? или тупо "теперь это поле не будет передаваться"?

[Касболат Кумахов]

Последнее.
Каждая выгрузка идет в базу (все версии).
Вышла новая версия. В ней нет поля. Но старая версия (она так же передается рядом с новой) это поле содержит. И оно идет в базу.
Другими словами, из новой версии поле исключили, но в старой оставили. В один период надо обрабатывать и новую и старую одновременно. Просто для новой отсутствующее поле получит некое дефолтное значение в базе.

[d-stream]

Касболат Кумахов, ну если xml десериализуется в nullable классы/поля - то все хорошо.
Нет в xml поля - значит после десериализации поле будет null (ну или заданым дефолтом).

И это уже можно писать в базу.

[Касболат Кумахов]

Обновил вопрос с примером.
Так наглядней.
Если следовать варианту "перевести XML_VER_1.0 в XML_VER_2.0", то последний должен будет выглядеть уже так:
XML_VER_2.0:

• FIELD_1: 10
  
• FIELD_2: 20
  
• FIELD_3: 30
  
• FIELD_4: 40
  

Но это примитивный пример.
Сам смысл полей может меняться от версии к версии.

[d-stream]

Касболат Кумахов,

Сам смысл полей может меняться от версии к версии.

Типа в прошлой версии это был пол клиента, а теперь вес, в следующей - рост? )))))

собственно в большинстве вариантов десериализации для некоего класса с полями FIELD_1, FIELD_2, FIELD_3, FIELD_4 при десериализации конструкции <>222444> поля FIELD_1 и FIELD_3 - как раз получат дефолтные значения.

[Касболат Кумахов]

Типа в прошлой версии это был пол клиента, а теперь вес, в следующей - рост?

Ну примерно так. Уже встретил нечто подобное.

В общем я понял Вашу идею. Разбавлять XML_VER_2.0 полями из XML_VER_1.0.
Но тогда надо и в скрипты вшивать это все. И не получится чистого XML_VER_2.0.
Мне кажется это усложнит весь процесс.

На SO подсказали заюзать напрямую svn, git, mercurial, you_name_it, как я и думал. Тупо переключать ветки.
Сейчас обдумываю этот вариант. Он чуть сложнее в реализации, но чище по коду и проще в сопровождении, как мне кажется.

[d-stream]

Касболат Кумахов, не надо замешивать. Отсутсвующие в xml поля при десериализации спровоцируют в модели установку дефолтов.

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