Обработка изменений класса при использовании ORM, такого как ODB
Я пытаюсь использовать ORM (Objection Relational Mapper), чтобы позволить мне сохранять мои объекты C ++ в базе данных SQLite. В настоящее время я рассматриваю ODB от CodeSynthesis.
Увидеть: http://www.codesynthesis.com/products/odb/
Глядя на документы для ODB, я не вижу ответа на мой надоедливый вопрос:
Что произойдет, если я создам класс, сохраню его в БД, но затем в более поздней версии моего продукта изменим класс. Когда пользователь получит новую версию моего программного обеспечения, как старые данные будут правильно загружены в новую версию класса?
Я смотрел на boost :: serialize и раньше, и у него есть механизмы для такого рода «апгрейдов», но мне интересно:
- Как это вообще делается в инструментах ORM?
- Как это сделать с ODB конкретно
- Есть ли лучший инструмент ORM, чем ODB для решения этой проблемы?
Решение
С самого начала полное раскрытие: я работаю на ODB. И чтобы ответить на ваш третий вопрос, нет, их нет ;-).
Серьезно, однако, эволюция схемы является сложной проблемой, и это один из трех больших элементов в нашем списке TODO (два других — поддержка нескольких баз данных и компилятор SQL-to-C ++). Хорошей новостью является то, что мы в значительной степени поработали с поддержкой нескольких баз данных, и следующая на очереди — эволюция схемы.
Как правило, кажется, что лучший подход — это привести вашу схему (и данные, если необходимо) к последней версии. Альтернатива создания приложения, способного читать несколько разных версий, просто не в масштабе в реальном мире.
В качестве примера, скажем, мы добавили элемент данных в класс, который на уровне схемы базы данных переводится как добавление столбца в соответствующую таблицу. Способ справиться с этим — сделать этот новый столбец NULL-совместимым (скажем, с помощью odb :: nullable или boost :: option). Идея заключается в том, что старые данные, которые не имеют значения для этого столбца, будут иметь значение NULL (которое приложение может обнаруживать и обрабатывать).
Далее нам нужно обновить схему в базе данных. В этом случае нам нужно будет выполнить инструкцию ALTER TABLE ADD COLUMN, которая добавит новый столбец. Как только ODB поддерживает эволюцию схемы, он автоматически генерирует эти операторы миграции. Прямо сейчас тебе придется написать их самому (боль в заднице, я знаю). Всем существующим строкам таблицы будет автоматически присвоено значение NULL для этого столбца.
Поэтому обычно приложение будет содержать наборы таких операторов, которые обновляют схему с одной версии на другую. Например, от 1 до 2, от 2 до 3 и т. Д. В базе данных будет храниться версия схемы, и приложение будет знать свою последнюю версию схемы. Незамедлительно после
При открытии базы данных приложение проверит версию базы данных и, если она ниже версии схемы приложения, запустит эти наборы миграции, чтобы обновить схему до последней версии.
Другие решения
Если вы все еще открыты для альтернативы ODB, вы можете рассмотреть айву: http://quince-lib.com (и полное раскрытие: я написал это).
По конкретному вопросу обновления вашего типа данных: айва автоматически не определяет необходимость эволюции, не разрабатывает стратегию эволюции или что-то в этом роде. Он дает вам интерфейс C ++ для ALTER TABLE. Но с положительной стороны: все это на уровне C ++: вы описываете свое изменение в терминах типов данных C ++, и все это статически проверяется на тип.