Блог

У меня есть модель под названием Post, в которой есть поле под названием Slug. Я пометил это поле атрибутом [ID] и изменил соглашение о FindIdentityProperty в RavenDB таким образом, что оно рассматривает свойство, помеченное [ID], как идентификатор документа.

Теперь я хочу получить все записи, в которых есть фрагменты, начинающиеся с символа G, нужно ли мне создавать подобный индекс :

 from Post in docs.Posts
select new { Slug = Post.Slug }
  

или вот так

 from Post in docs.Posts
select new { Id = Post.Id }
  

или я использую индекс, который должен быть у RavenDB внутри, поскольку я запрашиваю идентификатор.
Я понимаю, что у RavenDB где-то проиндексировано свойство ID, так что Session.Load<Post>("SomeID") возможно.

Первый вариант может быть определен в коде на C # как AbstractIndexCreationTask, потому что C # понимает, что Slug — это поле Post, но не работает, поскольку это «строка», введенная в RavenDB следующим образом: (когда происходит создание индекса)

 from Post in docs.Posts
select new { Slug = Post.Slug }
  

становится

 docs.Posts
    .Select(Post => new {Slug = Post.Slug })
  

Вы можете увидеть это, заглянув в SL-UI после создания индексов.

И это не работает, потому что ( как показано в SL-UI базы ДАННЫХ ) в представлении Post в формате JSON нет подобной пары имя-значение "Slug":"Some-Slug" . Поскольку это идентификатор, он показан над документом, а в @metadata его можно рассматривать как значение _document_id

Последний вариант действительно работает, но только когда определен как строка, как это в C#

 public class Post_ById : AbstractIndexCreationTask
    {
        public override IndexDefinition CreateIndexDefinition()
        {
            return new IndexDefinition
                       {
                           Map = "from Post in docs.Posts select new { Id = Post.Id}"
                       };
        }
    }
  

Я подозреваю, что когда Raven получает запросы, содержащие строку «Id«, он автоматически принимает это за запрос на [@metadata][_document_id].

Здесь нет хорошего LINQ — выглядит очень хрупким, не выдержит рефакторинга доменного имени. Id не является полем Post, но этот индекс позволил мне сделать то, что я хотел, а именно «извлекать все сообщения, в которых есть фрагменты, начинающиеся с символа G«. И я ненавижу определять индексы для идентификаторов, когда в базе данных уже должен быть такой индекс.

Хм, мы фактически используем те же соглашения и в AbstractIndexCreationTask, так что это должно сработать. В любом случае, к идентификатору документа всегда можно получить доступ, используя __document_id