【问题标题】:Different format RavenDB IDs on clustered server集群服务器上不同格式的 RavenDB ID
【发布时间】:2021-11-22 10:42:45
【问题描述】:

我们在 AWS 上有一个 DotNet Core API (C#) 和集群 RavenDB 服务器 (5.23)。创建文档时,ID 具有不同的格式,具体取决于客户端。如果使用 Swagger/Postman/xUnit 测试,我们会得到 Id="person/1234-C"。如果第三方调用端点,那么我们会得到 Id="Person/0000000000000001234-C"。请注意,第一个字符是一个小写,另一个是大写。在保存实体之前将 person.Id (string) 属性设置为 null。

ID 格式没有自定义配置。唯一的约定集是 MaxNumberOfRequestsPerSession。我已经阅读了关于 Ids (Server Id/Identity) 的文档,但我没有看到任何有用的东西。

为什么 Id 格式不同?如何确保它始终是正确的格式?不同国家、不同语言(但时区相同)的客户和 AWS 会以某种方式产生影响吗?

【问题讨论】:

    标签: ravendb


    【解决方案1】:

    你看过this的文章吗?

    格式Person/0000000000000001234-C由服务器生成
    Server-Side ID

    格式person/1234-C可以由服务器和客户端生成
    Hilo Algorithm

    【讨论】:

      【解决方案2】:

      RanenDB id 不区分大小写。 但这并没有改变情况。 如果您设置了特定的 id,RavenDB 将按原样使用它。

      短 id(“person/1234-C”)通常来自 Hilo 如果你使用 Hilo 生成 id,你有多种方法来控制前缀。

      1. 你可以注册 id 约定 - https://ravendb.net/docs/article-page/4.2/faq/client-api/configuration/identifier-generation/type-specific
      2. 您可以更改查找集合名称约定 - https://ravendb.net/docs/article-page/5.2/csharp/client-api/session/configuration/how-to-customize-collection-assignment-for-entities

      长ID(“Person/0000000000000001234-C”)通常来自服务器 要使用服务器端,您可以使用“Person/”(或“person/”,RavenDB 保留大小写)之类的前缀存储文档。

      https://ravendb.net/docs/article-page/5.0/csharp/server/kb/document-identifier-generation https://ravendb.net/docs/article-page/4.2/faq/client-api/configuration/identifier-generation/global

      https://github.com/ravendb/ravendb/discussions/13111

      class TestObj
      {
          public string Id { get; set; }
      }
      class TestObj3
      {
          public string Id { get; set; }
      }
      
      class TestObj2
      {
          public string Id { get; set; }
          public string Prop { get; set; }
      }
      
      [Fact]
      public async Task TestCase()
      {
          using var store = GetDocumentStore(new Options
          {
              ModifyDocumentStore = s =>
              {
                  s.Conventions.FindCollectionName = t => t == typeof(TestObj) ? t.Name.ToLower() : null;
                  s.Conventions.RegisterAsyncIdConvention<TestObj2>((s1, class2) => Task.FromResult($"testClass2/{class2.Prop}"));
              }
          });
          using (var session = store.OpenAsyncSession())
          {
              var testObj = new TestObj();
              await session.StoreAsync(testObj); // "testobj/1-A"
      
              var testObj2 = new TestObj2{Prop = "Something"}; 
              await session.StoreAsync(testObj2); // "testClass2/Something"
              
              var testObj3 = new TestObj3();
              await session.StoreAsync(testObj3); // "TestObj3s/1-A"
              
              var testObj4 = new TestObj3();
              await session.StoreAsync(testObj4, "TestObj/"); // "TestObj/0000000000000000006-A"
              
              var testObj5 = new TestObj3();
              await session.StoreAsync(testObj5, "testobj/"); // "TestObj/0000000000000000006-A"
              
              await session.SaveChangesAsync();
          }
      }
      

      【讨论】:

      • 我需要做什么才能始终使用正确的格式?服务器 ID 是我们集群的正确格式吗?我们使用默认的服务器行为。为什么默认服务器行为不总是集群中的服务器 ID?没有约定。实体 ID 属性在保存前设置为 null。获得“正确”格式以对我们系统中的每种文档类型都有约定的唯一方法是什么?
      • 我不确定您所说的“正确格式”是什么意思。你可以使用任何你想要的方法。如果您想要一致性,您应该在整个系统中使用相同的方法。
      • 我认为在集群方面使用一种格式而不是另一种格式会有技术优势。即推荐的聚类格式。我很欣赏文档提到在进行大量批量插入但我们没有很多批量插入的情况下建议使用某些格式。
      • 这两种格式都是为集群设计的,通过添加生成它的节点标签。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2015-10-18
      • 2015-05-31
      • 1970-01-01
      • 1970-01-01
      • 2015-03-22
      • 2010-12-06
      • 1970-01-01
      相关资源
      最近更新 更多