Схемы очень часто изменяются с выходом новых версий программы. Общающиеся программы обновляются не синхронно и надо как-то им уметь продолжать общение несмотря на то что у кого-то схема новее, у кого-то древнее. Так же сохраненные данные могут быть старой версии.
Для этого схемы должны обладать совместимостью. Совместимость бывает прямой и обратной, давайте рассмотрим оба случая.
Обратная совместимость означает, что данные сериализованные старой версией схемы могут быть десериализованны новой версией.
Прямая совместимость означает, что данные сериализованные с новой версией схемы могут быть десериализованны старой версией.
Как такое возможно? Десериализатор должен узнать какая версия схемы у данных, либо снаружи, либо из данных. А так же должна быть стратегия того, как конвертировать данные, например какое значение новым полям указать.
Это уже сразу несколько вариантов. Alkahest точно будет поддерживать вариант с указанием версии снаружи и указанием версии прямо в данных.
Но скорее всего не будет варианта с указанием в данных версии для субструктур, всё дерево схемы будет с одной версией.
С прямой совместимостью есть еще вариант без указания версии. Если новая версия строго шире старой, то десериализатор со старой схемой просто игнорирует хвост.
Тут помогает сериализация с указателем, потому что размер поля указателя фиксированный, так что схема может обладать прямой совместимостью и не влиять на схему, полем которой она является, если используется указатель.
То есть если было:
formula A = { ... }
formula B = { ... }
formula Foo = {
a: A,
b: B,
};
formula Bar = {
a: &A,
b: &B,
};То старая формула
Foo не будет совместимой с новой версией, если A расширилось, а Bar будет.Что тут будет делать Alkahest? Проверять совместимость! Автор схемы указывает вид совместимости, а функция верификации убедится, что новая схема обладает указанной совместимостью со старой схемой.
Ультой будет проверка диффа кода на наличие несовместимых изменений схемы. И GitHub Action для запуска этой проверки в PR.