Linq 쿼리의 SharePoint 조회 (백분위와 관련된) 값

Question

두 개의 목록, 게시물 및 설명이 있습니다. 주석에는 게시물 목록에 대한 조회 열이 있고 게시물에는 주석 목록에 대한 조회 (계수 관계) 관계가 있습니다. 내가하려는 일은 각 게시물의 댓글 수를 표시하는 것입니다. 어떤 이유로 엔티티 참조로이 작업을 수행하는 방법을 알 수 없습니다. 다음

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() 
         }; 

내가 몇 가지 방법을 시도하고 오류의 다양한 얻을

가 나는 ArchiveItem 클래스가 메시지. 이 특정 버전은 나를 제공합니다

쿼리는 둘 이상의 목록에 대한 참조 또는 EntityRef/EntitySet을 사용하여 전체 엔터티의 투영과 같이 지원되지 않는 요소를 사용합니다.

아이디어가 있으십니까? 나는 이것이 매우 간단하다고 생각했지만, 아마도 나는 뭔가를 놓치고 있습니다.

Answer 1

Linq-to-Sharepoint는 조인을 지원하지 않습니다. 셰어 포인트 목록은 실제 데이터베이스에서 별도의 테이블이 아니므로 셰어 포인트의 실제 데이터 모델은 중요하지 않지만 평범한 SQL에서 논리적이고 저렴한 연산은 CAML에서 그다지 쉽지 않다는 것을 명심해야합니다. 모든 Linq - Sharepoint 쿼리는 궁극적으로 CAML로 변환됩니다.

아무리해도 조인은 구현되지 않습니다. 조회 열의 엔티티를 사용하여 데이터를 가져올 수는 있지만 배경에서는 항상 다른 쿼리로 구현되며 내 경험상 이러한 lookup'd-entities에는 집계 또는 다른 다중 레코드 작업을 사용할 수 없습니다. 카운트().

카운트가 쉬운 기능이기 때문에 아마도이 문제를 해결할 수있는 좋은 방법이 있습니다. 나는 당신이 배열 (또는 비슷한)을 세고 싶어하는 속성을 변환하려고 시도 할 것이고, 그것의 길이 나 개수를 사용하려고 할 것이다.

일반적으로 이러한 문제를 해결하는 방법은 코드에서 데이터 처리를 수행하고 매우 조잡한 쿼리를 사용하는 것입니다. 올바른 데이터 구조를 선택하는 데 약간의주의를 기울임으로써 작업 속도를 향상시킬 수 있습니다. 여러 경우에 걸쳐 첫 번째 경우의 쿼리가 데이터베이스에 일정량의 불필요한 데이터 트래픽을 생성 했음에도 불구하고 linq-to-sharepoint 쿼리 솔루션을 사용하여 코드 처리를 통해보다 나은 성능을 경험했습니다.

한 가지 더 : CAML 또는 코드를 사용하여 Sharepoint List를 생성하려는 경우 개발 중에 만 '클릭 된'콘텐츠 유형/목록을 사용하는 경우 SPMetal에서 생성하는 클래스에 차이가 있음을 유의하십시오. 이 경우. 특히, 조회 필드는 Entity 클래스가 아니라 두 개의 일반 필드로 표시됩니다. 항목 ID 및 제목이 하나 있습니다 (SPListItem에서 더 비슷 함). 또한 역방향 조회 엔티티 집합이 전혀 존재하지 않습니다. 나는 이것에 관한 문서를 보지 못했지만 그것을 경험했다. 따라서 CAML 생성 사이트를 사용하려는 경우 쿼리 중 일부를 재고해야 할 수도 있습니다. 해결 방법이있을 수 있지만 내 경험에 조회 엔티티 (집합) 어쨌든 매우 느린 및 일반적인 linq 쿼리를 사용하는 것이 좋습니다.

이 정보가 도움이되기를 바랍니다.