Drupal에서 원격 데이터 구조를 통합하기위한 많은 전략을 보았습니다. 특정 모듈이 안정화되고 사용 사례가 시도됨에 따라 전략이 발전하는 것처럼 보였습니다.

REST API를 통해 노출되는 여러 데이터 유형 (market, market_hours, vender, stall, produce) 등으로 표시되는 데이터 구조 "Farmers Markets"가 있다고 가정하십시오. 외부 서비스의 ID는 Drupal과 관련이 있어야합니다. 즉 "market"을로드 할 때 'market_hours'및 'stall'에서 데이터를 가져와야합니다. Drupal에서 정기적으로 동기화되는 읽기 전용 콘텐츠로 표시하는 가장 좋은 방법은 무엇입니까?

다음 기준으로 이것을 평가하려고합니다.

Drupal의 데이터 구조 :

노드 및 사용자 지정 엔터티

내가 본 웹 서비스와 관련된 많은 시나리오는 사용자 지정 엔터티를 사용합니다. CRUD op를 단순화합니다. 그러나 이러한 항목은 공개적으로 볼 수 있다는 점에서 "콘텐츠"입니다.

저장소 (로컬 대 원격) :

서비스가 원격 엔티티로로드되는 몇 가지 예를 보았습니다.이 모듈은 https://drupal.org/project/wsdata 라이브러리를 만듭니다 . 이것은 가장 매력적으로 들리지만 많은 사용 사례를 보지 못했습니다. 사용자 정의 코드의 예도 있습니다 : https://drupal.org/sandbox/fago/1493180

데이터 동기화 :

피드 대 마이그레이션 대 Guzzle 대 '웹 서비스 클라이언트'대 '웹 서비스 데이터'

여러 가지 옵션이 있습니다. 피드는 이제 엔티티를 지원합니다. 마이그레이션은 피드, 특히 사용자 지정 시나리오보다 훨씬 깔끔해 보입니다. 또한 원격 서비스와 동기화하기 위해 guzzle 클라이언트를 사용하는 사람들을 보았습니다 : http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ckan.drush. inc # l273 . 또한 WS 클라이언트 모듈 https://drupal.org/project/wsclient 가 나머지 클라이언트로 특별히 작성된 옵션을 제공하는 것으로 나타났습니다 . 웹 서비스 데이터는 서비스에서 직접로드되어 로컬로 캐시됩니다.

어떤 생각에 감사드립니다.

1. 질문 재구성

귀하의 예에서는 데이터가 Drupal 측에서만 읽히고 단방향 동기화 만 사용하도록 제안합니다. 로컬 캐싱이 Drupal 데이터베이스의 엔티티가 되더라도 구현하는 솔루션은 원격 스토리지, 동기화 및 로컬 캐싱의 변형이 될 것이기 때문에 이것이 여기서 고려해야 할 가장 중요한 요소라고 생각합니다.

따라서 "로컬 스토리지 대 원격 스토리지"가 아닌 다음과 같은 질문이 있습니다.

• 데이터를 로컬로 캐시해야합니까?
• 데이터를 실제 엔티티로 캐시하고 피드 (또는 유사한)를 사용하여 데이터를 정기적으로 동기화해야합니다. 또는
• 동기화 및 캐싱을 제공하는 사용자 정의 모듈을 사용해야합니다.

관심이있을만한 기사는 " Drupal 7의 원격 엔터티 "에 있습니다.

2. 데이터 캐싱

일반적으로 데이터를 캐싱하는 것이 좋습니다.

• 다른 서비스의 중단 또는 연결 시간 초과로부터 보호됩니다.

• Drupal 데이터베이스에 데이터가 있으면 작업 속도가 빨라집니다.

• Drupal 데이터베이스에 데이터가 있으면 뷰와 같은 다른 모듈과의 통합 가능성이 높아집니다 (이는 보장되지는 않습니다).

데이터를 캐싱하지 않는 유일한 장점은 오래된 데이터를 얻지 못한다는 것입니다. 어떤 경우에는 바람직하지 않습니다. 때로는 오래된 데이터보다는 데이터를 표시하지 않는 것이 좋습니다. 나는 이것이 당신이 제공 한 예제에서 이점으로 보지 않으므로 로컬 캐싱과 관련된 솔루션 에이 답변에 중점을 둘 것입니다.

3. 로컬 엔터티 + 동기화

로컬 엔터티를 가지고 직접 동기화하는 옵션을 선택하면 원래 질문으로 돌아갑니다.

• 노드 또는 사용자 지정 엔터티를 사용해야합니까?

• 동기화에 가장 적합한 모듈

3.1 노드와 사용자 지정 엔터티

• 노드가 정확히 무엇인지에 대한 정의는 매우 개방적입니다. 노드 의 문서 페이지 는 노드가 데이터에 적용되지 않는 사이트에 "저장"된 "게시"되고 있음을 나타냅니다.

• Drupal 개발자는 어떤 것이 노드 인 경우 사이트 자체에서이를 조작 할 수 있어야합니다.

• Drupal 사용자로서 노드도 편집 할 수있을 것으로 기대합니다.

• 이 Drupal 8 호 https://drupal.org/node/2019031 은 "읽기 전용"개념이 번들 수준이 아닌 엔티티 수준에서 적용되는 개념임을 시사합니다. 이것이 구현되면이 경로를 따라 가면 도움이 될 것입니다.

요약하면 : 데이터는 읽기 전용 이며 원격으로 저장 되는 것은 사용자 지정 엔터티 유형을 사용하여 데이터를 나타내는 것이 더 합리적입니다.

3.2 동기화

두 번째 부분의 경우 두 가지 주요 모듈은 Feeds and Migrate 입니다.

피드와 마이그레이션의 차이점은 피드는 정기적으로 컨텐츠를 가져 오기 위해 빌드되는 반면, 마이그레이션은 컨텐츠를 한 곳에서 다른 곳으로 한 번에 포팅하기 위해 빌드된다는 것입니다. 마이그레이션은 기존 데이터 업데이트를 지원하지만 두 모듈이 모두 잘 지원되면 작업에 맞게 작성된 모듈을 사용하는 것이 더 합리적입니다. 피드가 더 적합합니다.

두 모듈을 모두 직접 사용한 경우 (피드백을위한 피드, 마이그레이션을위한 피드) 피드가 마이그레이션보다 더 지저분하지 않습니다. 전체 사이트를 마이그레이션하는 것이 단일 콘텐츠 유형을 가져 오는 것보다 복잡하기 때문에 마이그레이션에는 내 경험에 더 많은 사용자 지정 코드가 필요했기 때문에 비교하기가 어렵습니다.

4. 원격 저장소, 동기화 + 캐싱을위한 사용자 정의 모듈

이 작업에 도움이되는 많은 모듈이 있습니다.

당신이 언급 한 웹 서비스 데이터 모듈을, 그리고 다른 사람이 언급 한 데이터 모듈을 . 고려해야 할 또 다른 옵션은 원격 엔터티 API 모듈 입니다. 내가 경험 한 것 중 유일한 것은 데이터 모듈입니다.

• 웹 서비스 데이터 모듈에는 아직 릴리스가 없습니다. 코드가 아직 안정적이지 않음을 나타내거나 API가 변경 될 수 있습니다. 프로젝트 필드에 따라 엔티티 필드 쿼리를 지원하지 않으며 코드 저장소를 빠르게 탐색하면 뷰 지원이 있다는 증거가 표시되지 않으므로 뷰를 사용하여 엔티티를 표시 할 수 없습니다.

• 내 경험상 데이터 모듈은 테이블에 데이터가 있고 뷰에 노출하려는 비 개발자에게 더 지향적입니다. Drupal 6 버전은 사용하기에 상당히 실망 스러웠습니다.

• 원격 엔터티 API 모듈은 상당히 유망한 것으로 들립니다. 원격 엔터티의 페치 및 캐싱을 지원하며 뷰를 지원합니다. 알파 릴리스에만 있으므로 API가 여전히 변경 될 수 있습니다. 언뜻 보면 엔터티 필드 쿼리를 지원하지 않는 것 같으며 한 가지 유형의 원격 서비스 만 지원하므로 직접 구현해야합니다.

결론

원격 스토리지 모듈 중 어느 것도 엔티티 필드 쿼리를 지원하지 않으므로 실제 엔티티 + 피드를 사용하는 것이 Drupal 사이트와 최상의 통합을 제공하는 솔루션입니다.

Views 지원이 충분하고 Entity Field Queries를 통해 다른 모듈과의 잠재적 통합에 대해 걱정하지 않는다면 Remote Entity API를 사용하는 것이 좋습니다. 그러나 자체 원격 인터페이스를 구현해야합니다.

내 의견으로는 뷰, 규칙, 토큰, 크루 드 훅, 검색 API 및 강력한 시스템 통합이 필요한 경우 노드로 간주 될 수 없지만 데이터베이스에 "엔티티 ID"및 "외부 ID"관계 및 "엔티티 속성"에 캡슐화 된 정보 호출 검색 마지막으로 데이터 동기화를 위해 선택한 도구에 관계없이 cron Queues로 처리합니다.

데이터를 정확하게 검색하고 노출해야하는 경우 외부 데이터를 검색하기위한 인터페이스 클래스를 만들고 "Farmers Markets"구조에서 정보를 검색하는 클래스로이 인터페이스를 구현하는 것이 더 나은 선택이라고 생각합니다.

문안 인사

기본 데이터베이스 엔진 이외의 플러그 가능 스토리지 백엔드를 허용 하는 Field Storage API 가 있습니다.