Значение поиска в SharePoint (количество связанных) в запросе Linq - PullRequest
Новая
       29

Значение поиска в SharePoint (количество связанных) в запросе Linq

0 голосов
/ 22 апреля 2011

У меня есть два списка, сообщения и комментарии.Комментарии имеют столбец «Уточняющий запрос» к списку «Сообщения», а «Сообщения» имеют отношение «Уточняющий запрос (относительное число)» к списку «Комментарии».То, что я пытаюсь сделать, это просто отображать количество комментариев в каждом сообщении.По какой-то причине я не могу понять, как это сделать с помощью Entity References.

У меня есть класс ArchiveItem: 

    public class ArchiveItem
    {
        public string Id { get; set; }
        public string Title { get; set; }
        public string Comments { get; set; }
        public string Date { get; set; }
    }

А затем запрос, который я пытаюсь выполнить:

        var queryItems = from item in spotlightItems
                         join comment in commentItems on item.Title equals comment.Title
                         select new ArchiveItem
                         {
                             Id = item.Id.ToString(),
                             Title = item.Title,
                             Comments = comment.Post.Title.Count().ToString(),
                             Date = item.Date.ToString()
                         };

Я пробовал несколько разных способов и получаю различные сообщения об ошибках.Эта конкретная версия дает мне

В запросе используются неподдерживаемые элементы, такие как ссылки на несколько списков или проекция полной сущности с использованием EntityRef / EntitySet.

Есть идеи?Я думал, что это будет довольно просто, но, может быть, я что-то упустил.

1 Ответ

0 голосов
/ 23 апреля 2011

Linq-to-Sharepoint не поддерживает объединения. Список sharepoint не является отдельной таблицей в реальной базе данных, фактическая модель данных sharepoint не имеет значения, но вы должны иметь в виду, что логичная и дешевая операция в обычном SQL не так проста как таковая в CAML, и каждый запрос Linq-to-Sharepoint в конечном итоге преобразуется в CAML.

Во всяком случае, объединения не реализованы. Вы можете использовать Entity столбцов поиска для получения данных, но в фоновом режиме это всегда реализуется как другой запрос, и по моему опыту вы не можете использовать какие-либо агрегатные или другие операции с несколькими записями для этих объектов поиска, включая Count ().

Вероятно, есть хороший способ обойти это, потому что подсчет является такой простой функцией. Я бы попытался преобразовать свойство, которое вы хотите сосчитать, в массив (или аналогичный) и использовать его длину или количество.

В общем, решение этих проблем заключается в том, чтобы обрабатывать данные в вашем коде и полагаться на довольно грубые запросы. И, вложив некоторую осторожность в выбор правильных структур данных, вы сможете очень быстро ускорить операции. В нескольких случаях я испытывал лучшую производительность при обработке кода, чем при использовании решений запросов linq-to-sharepoint, хотя запросы в первом случае приводили к определенному количеству ненужного трафика данных в базу данных.

Еще одна вещь: если вы планируете в конечном итоге создавать списки Sharepoint, используя CAML или код, и вы используете «щелкнувшие» типы / списки содержимого только во время разработки, имейте в виду, что в этих классах SPMetal генерирует различия случаев. В частности, поля поиска представлены не как классы сущностей, а как два обычных поля, с идентификатором элемента и одним с заголовком (больше как в SPListItem). Кроме того, наборы обратного поиска-сущности вообще отсутствуют. Я не видел документации об этом, но я испытал это. Следовательно, вам может понадобиться переосмыслить некоторые из ваших запросов, если вы планируете использовать сайт, созданный на CAML. Может быть обходной путь, но по моему опыту Lookup Entity (наборы) в любом случае очень медленный, и лучше использовать обычный запрос linq.

Надеюсь, это поможет.

...