改变“模式”在 RavenDB 中

Question

只是为了扩展我的知识，我开始研究各种 NoSQL 选项。我访问的第一个是 RavenDB，它看起来很有趣。我仍在尝试打破我根深蒂固的关系思维，以及典型的 RDBMS 维护例程。

在我日常处理实体框架时，我们会经历编写数据库更改脚本、刷新 EF 映射模型等例程。它在 NoSQL 中（尤其是 RavenDB）如何工作？一旦应用程序上线，如何更改各种 POCO 对象等并将其部署到生产环境？存储在旧 POCO 类中的数据会发生什么情况？

我还没有深入研究或愤怒地使用Raven DB。一旦我这样做了，这可能是显而易见的，但我很想事先知道，这样我就不会把自己编码到角落里。

谢谢， D .

Answer 1

它们保持原样 - 加载时不再存在的属性将被忽略（并在更改时丢失），并且丢失的属性将返回为 null，

建议您使用基于集合的操作来保持数据与对象模型的检查。

哦，看看我，我现在在计算机上！

基本上，在迁移到文档存储时，您正确地认识到您失去了一些功能并在数据库中获得了一些自由您已经定义了预先架构，并且尝试上传与该架构不匹配的数据将导致错误。

然而，重要的是要认识到无模式和无结构之间存在差异，因为您的文档都包含自己的结构（表示属性名称和属性值的键/值对）。

这使得它对于编写一些代码并保存数据的整个“刚刚开始”的因素很有用 - 但是当很容易改变代码结构时，很难将其与已经保存的数据相协调。

此时会出现一些策略：

• 一旦持久化了数据，就使结构不可变，对类进行版本控制
• 允许修改结构，但使用基于集合的操作来更新数据以匹配新结构
• 允许修改结构，并编写代码来处理加载数据时出现不一致

第三个显然是一个坏主意，因为它会导致无法维护的代码，如果您只是存储事件或其他此类数据，但对大多数情况来说并不适合，那么版本控制您的类可以工作，所以您'剩下中间的选项。

我建议这样做，并遵循一些简单的规则，这些规则与处理关系数据库中的预先模式时遵循的规则相同。

• 使用 VCS 系统确定已部署版本之间的更改
• 编写从一个版本升级到另一个版本的迁移脚本
• 请小心重命名/删除属性 - 因为如果这些属性不存在，加载文档和保存文档将导致数据丢失新文档

等。

我希望这更有帮助:-)

Answer 2

RavenDB 将您的 .NET 对象序列化为 JSON 格式。没有架构。

如果将一些对象添加到数据库中，它们将被序列化。如果向要序列化的类型添加一些属性，则已存储的对象将缺少这些属性。

Answer 3

Ayende 撰写的这篇文章介绍了如何执行从版本 1 到版本 2 的迁移（在本例中将“Name”属性更改为“FirstName”和“LastName”属性。

http://ayende.com/blog/66563/ravendb-migrations-rolling-updates

基本上，监听器是在 DocumentStore 中注册的：

documentStore.RegisterListener(new CustomerVersion1ToVersion2Converter())

示例实现摘自上述文章：

public class CustomerVersion1ToVersion2Converter : IDocumentConversionListener
{
    public void EntityToDocument(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;

        metadata["Customer-Schema-Version"] = 2;
        // preserve the old Name property, for now.
        document["Name"] = c.FirstName + " " + c.LastName;
        document["Email"] = c.CustomerEmail;
    }

    public void DocumentToEntity(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;
        if (metadata.Value<int>("Customer-Schema-Version") >= 2)
            return;

        c.FirstName = document.Value<string>("Name").Split().First();
        c.LastName = document.Value<string>("Name").Split().Last();
        c.CustomerEmail = document.Value<string>("Email");
    }
}

Answer 4

与其说没有架构管理，不如将其移至代码中，这样代码中的对象与数据库中的对象之间永远不会不匹配。

处理更改的第一部分是确保您使用可以处理缺失/额外值的序列化程序 - 如果数据中未定义字段，请将其设置为 null。如果数据中的字段与对象的属性不匹配，请忽略它。

大多数更改都可以处理，无需更多操作 - 要么有一个新字段，并且您无论如何都需要为现有记录设置默认值，要么有一个您不再关心的旧字段。

对于更复杂的更改，例如重命名/组合字段或更改数据格式，请向对象添加新字段而不删除旧字段，并让您的加载方法从旧字段传输数据。当您保存记录时，它将采用新格式。该代码可以永久保留在适当的位置，根据需要更新数据，也可以设置一次性流程来为所有现有对象调用相同的代码。请注意，与 SQL 脚本不同，即使在大型数据集上运行需要很长时间，这种类型的更新也不需要停机，因为代码可以处理旧格式和新格式。