在不使用默认 ID 生成策略时,如何加载受限于集合的 RavenDB 文档

2023-12-30

在 RavenDB 4 (v4.0.3-patch-40031) 中,我有两种文档类型:Apple and Orange。两者具有相似但又不同的属性。我在运行时遇到代码中的一个错误,有时会提供 Apple 的 ID,但会返回 Orange。可怕的!

深究起来,还是有几分道理的。但我正在努力寻找合适的解决方案。

开始。在RavenDB中,我存储了一个Apple作为文档:

id: "078ff39b-da50-4405-9615-86b0d185ba17"
{
    "Name": "Elstar",
    "@metadata": {
        "@collection": "Apples",
        "Raven-Clr-Type": "FruitTest.Apple, FruitTest"
    }
}

为了这个例子,假设我没有Orange存储在数据库中的文档。我希望这个测试能够成功:

// arrange - use the ID of an apple, which does not exist in Orange collection
var id_of_apple = "078ff39b-da50-4405-9615-86b0d185ba17";

// act - load an Orange
var target = await _session.LoadAsync<Orange>("078ff39b-da50-4405-9615-86b0d185ba17");

// assert - should be null, because there is no Orange with that Id
target.Should().BeNull(because: "provided ID is not of an Orange but of an Apple");

...但是失败了。发生的情况是文档 ID 存在,因此 RavenDB 加载该文档。不关心它是什么类型。它会尝试自动映射属性。我预期或错误地假设加载类型说明符会将查找限制为该特定文档集合。相反,它会抓取并映射整个数据库,而不是限制它type <T>。所以行为不同于.Query<T>,它对集合进行约束。

需要注意的是,我正在使用指南作为身份策略,通过将 Id 设置为string.Empty(符合the docs https://ravendb.net/docs/article-page/4.0/csharp/client-api/document-identifiers/working-with-document-identifiers#autogenerated-ids)。我假设默认的ID策略,就像entityname/1001,就不会有这个问题。

The 有关加载实体的文档 https://ravendb.net/docs/article-page/4.0/csharp/client-api/session/loading-entities不要真正提及这是有意还是无意。它只说:“从数据库下载文档并将其转换为实体。".

但是,由于某些原因,我确实想将 Load 操作限制为单个集合。或者,更好的说法是,尽可能高效地通过 ID 从特定集合中加载文档。如果不存在则返回null。

AFAIK,有两种选择可以实现这一目标:

  1. 使用更贵的.Query<T>.Where(x => x.Id == id), 代替.Load<T>(id)
  2. Do the .Load<T>(id)首先然后检查(~不知何故,见底部)它是否是集合 T 的一部分

我的问题可以概括为两个问题:

  1. 除了上述两种选择之外,是否还有另一种更高效或更稳定的方法?
  2. 如果没有,那么在这两个选项中,哪一个在性能和稳定性方面是推荐的?

特别是对于第二个问题,很难正确地衡量这一点。至于稳定性,例如没有副作用,我想对 RavenDB 内部结构有更深入了解或经验的人可能会对此有所了解。

注意:该问题假设所解释的行为是故意的,而不是 RavenDB 错误。

〜不知何故会是:

public async Task<T> Get(string id)
{
    var instance = await _session.LoadAsync<T>(id);
    if (instance == null) return null;

    // the "somehow" check for collection
    var expectedTypeName = string.Concat(typeof(T).Name, "s");
    var actualTypeName = _session.Advanced.GetMetadataFor(instance)[Constants.Documents.Metadata.Collection].ToString();
    if (actualTypeName != expectedTypeName)
    {
        // Edge case: Apple != Orange
        return null;
    }

    return instance;
}

如何重现

2018/04/19 更新 - 在有用的评论后添加了这个可重现的示例(感谢)。

Models

public interface IFruit
{
    string Id { get; set; }
    string Name { get; set; }
}

public class Apple : IFruit
{
    public string Id { get; set; }
    public string Name { get; set; }
}

public class Orange : IFruit
{
    public string Id { get; set; }
    public string Name { get; set; }
}

Tests
例如。在同一会话中抛出 InvalidCastException (有效),但在第二个会话中则不然。

public class UnitTest1
{
    [Fact]
    public async Task SameSession_Works_And_Throws_InvalidCastException()
    {
        var store = new DocumentStore()
        {
            Urls = new[] {"http://192.168.99.100:32772"},
            Database = "fruit"
        }.Initialize();

        using (var session = store.OpenAsyncSession())
        {
            var apple = new Apple
            {
                Id = Guid.NewGuid().ToString(),
                Name = "Elstar"
            };

            await session.StoreAsync(apple);
            await session.SaveChangesAsync();

            await Assert.ThrowsAsync<InvalidCastException>(() => session.LoadAsync<Orange>(apple.Id));
        }
    }

    [Fact]
    public async Task Different_Session_Fails()
    {
        var store = new DocumentStore()
        {
            Urls = new[] {"http://192.168.99.100:32772"},
            Database = "fruit"
        }.Initialize();

        using (var session = store.OpenAsyncSession())
        {
            var appleId = "ca5d9fd0-475b-41de-a1ab-57bb1e3ce018";

            // this *should* break, because... it's an apple
            // ... but it doesn't - it returns an ORANGE
            var orange = await session.LoadAsync<Orange>(appleId);

            await Assert.ThrowsAsync<InvalidCastException>(() => session.LoadAsync<Orange>(appleId));
        }
    }
}

.Query<T>.Where(x => x.Id == id)是要走的路。在RavenDB 4.0中,通过ID进行的查询由幕后的文档存储直接处理(而不是通过索引),因此它的效率与Load.

您的方案的优点是查询的范围仅限于指定的集合。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

在不使用默认 ID 生成策略时,如何加载受限于集合的 RavenDB 文档 的相关文章

随机推荐