使用ORM（如ODB）时处理类更改 [英] Handling class changes when using ORM such as ODB
问题描述
我正在使用ORM（Objection Relational Mapper）来允许我将我的C ++对象持久化到SQLite数据库中。我目前正在通过代码合成考虑ODB。
I am looking into using an ORM (Objection Relational Mapper) to allow me to persist my C++ objects into an SQLite database. I'm currently considering ODB by CodeSynthesis.
参见： http://www.codesynthesis.com/products/odb/
查看ODB的文档，我没有看到我有一个叨叨的问题，这是：
Looking at the docs for ODB, I don't see an answer to a nagging question I have, which is:
如果我创建一个类，持久保存到数据库会发生什么，但是在我的产品的更高版本更改类。当用户获得我的软件的新版本时，旧数据将如何正确加载到新版本的类中？
What happens if I create a class, persist it to the DB, but then in a later version of my product change the class. When the user gets the new version of my software, how will the old data get loaded properly into the new version of the class?
我看过boost ::序列化，它有处理这种升级的机制，但我想知道：
I've looked at boost::serialize before and it has mechanisms to handle this kind of "upgrading", but I'm wondering:
- 如何在ORM工具
- 有没有比ODB更好的ORM工具来处理这个问题？
推荐答案
从一开始，全面披露：我在ODB工作。回答你的第三个问题，不，没有任何; - ）。
From the outset, full disclosure: I work on ODB. And to answer your third question, no, there aren't any ;-).
然而，严重的是，模式演化是一个困难的问题，我们的TODO列表中的大项目（另外两个是多数据库支持和SQL到C ++编译器）。好消息是，我们已经完成了多数据库支持，下一个是在架构演化。
Seriously, though, schema evolution is a hard problem and it is one of the three big items on our TODO list (the other two are multi-database support and SQL-to-C++ compiler). The good news is that we are pretty much done with multi-database support and the next one in line is schema evolution.
一般来说，似乎最好的方法是带来您的模式（和数据，如果必要）到最新版本。使应用程序能够读取多个不同版本的替代方案似乎在现实世界中似乎并不规模。
Generally, it seems the best approach is to bring your schema (and the data, if necessary) to the latest version. The alternative of making the application capable of reading multiple different versions just doesn't seem to scale in the real world.
例如，我们向类添加了一个数据成员，该数据成员在数据库模式级别中转换为向相应表中添加列。处理这个的方法是使这个新列为NULL（使用，例如，odb :: nullable或boost :: optional）。这里的想法是，没有这个列的值的旧数据将是NULL（应用程序可以检测和处理）。
As an example, let's say we added a data member to the class which in the database schema level translates to adding a column to the corresponding table. The way to handle this is to make this new column NULL-able (with, say, odb::nullable or boost::optional). The idea here is that old data that doesn't have a value for this column will be NULL (which the application can detect and handle).
接下来我们需要升级数据库中的模式。在这种情况下，我们需要执行ALTER TABLE ADD COLUMN语句，它将添加新的列。一旦ODB支持模式演进，它将自动生成这些迁移语句。现在你必须自己写（在屁股的痛苦，我知道）。表中的所有现有行将自动为此列分配NULL值。
Next we need to upgrade the schema in the database. In this case we will need to execute the ALTER TABLE ADD COLUMN statement which will add the new column. Once ODB supports schema evolution, it will generate these migration statements automatically. Right now you will have to write them yourself (pain in the ass, I know). All the existing rows in the table will be automatically assigned NULL value for this column.
因此，通常应用程序将包含一组此类语句，将模式从一个版本升级到下一个。例如，从1到2，从2到3等。数据库将存储模式版本，并且应用将知道其最新的模式版本。在
打开数据库之后，应用程序将立即检查数据库版本，如果它低于应用程序模式版本，它将开始运行这些迁移集以将模式升级到最新版本。
So normally an application will contain sets of such statements that upgrade the schema from one version to the next. E.g., from 1 to 2, from 2 to 3, etc. The database will store the schema version and the application will know its latest schema version. Immediately after opening the database, the application will check the database version and if it is below the application schema version, it will start running these migration sets to upgrade the schema to the latest version.
这篇关于使用ORM（如ODB）时处理类更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
