我正在研究使用ORM（异议关系映射器）来允许我将C ++对象持久化到SQLite数据库中。我目前正在通过CodeSynthesis考虑ODB。
请参阅：http://www.codesynthesis.com/products/odb/
查看ODB的文档，我没有看到一个唠叨问题的答案，即：
如果我创建一个类，将其持久保存到数据库中会发生什么，但随后在我的产品的更高版本中更改该类。当用户获得我的软件的新版本时，如何将旧数据正确加载到新版本的类中？
我之前看过boost :: serialize并且它有处理这种“升级”的机制，但我想知道：
答案 0 :(得分：7)
从一开始，全面披露：我在ODB工作。并回答你的第三个问题，不，没有; - ）。
但是，严重的是，模式演变是一个难题，它是我们TODO列表中的三大项目之一（另外两个是多数据库支持和SQL-to-C ++编译器）。好消息是我们已经完成了多数据库支持，下一个是模式演变。
通常，最好的方法是将您的架构（以及必要时的数据）带到最新版本。使应用程序能够读取多个不同版本的替代方案似乎在现实世界中似乎没有扩展。
作为一个例子，假设我们在类中添加了一个数据成员，该数据成员在数据库模式级别转换为向相应的表添加列。处理这个问题的方法是使这个新列成为NULL（使用odb :: nullable或boost :: optional）。这里的想法是，没有此列值的旧数据将为NULL（应用程序可以检测和处理）。
接下来，我们需要升级数据库中的架构。在这种情况下，我们需要执行ALTER TABLE ADD COLUMN语句，该语句将添加新列。一旦ODB支持模式演变，它将自动生成这些迁移语句。现在你必须自己写（痛苦，我知道）。表中的所有现有行都将自动为此列分配NULL值。
通常，应用程序将包含一组此类语句，用于将模式从一个版本升级到下一个版本。例如，从1到2，从2到3等。数据库将存储模式版本，应用程序将知道其最新的模式版本。之后立马 打开数据库，应用程序将检查数据库版本，如果它低于应用程序架构版本，它将开始运行这些迁移集以将架构升级到最新版本。
答案 1 :(得分：0)
如果你仍然对ODB持开放态度，你可以考虑qu :: http://quince-lib.com（并完全披露：我写了它）。
关于升级数据类型的具体问题：quince不会自动检测是否需要进化，或设计进化策略或类似的东西。它给你的是ALTER TABLE的C ++接口。但从积极的方面来说：它完全处于C ++级别：您根据C ++数据类型描述了您的更改，并且它们都是静态类型检查的。