ฉันได้เห็นกลยุทธ์หลายประการสำหรับการรวมโครงสร้างข้อมูลระยะไกลใน Drupal ดูเหมือนว่ากลยุทธ์จะค่อยๆพัฒนาขึ้นเนื่องจากโมดูลบางตัวมีความเสถียรและมีการใช้เคสต่างๆ

ลองนึกภาพเรามีโครงสร้างข้อมูล "ตลาดของเกษตรกร" ที่แสดงโดยประเภทข้อมูลจำนวนมาก (ตลาด, ตลาด _hours, ผู้ขาย, แผงลอย, ผลิตผล) เป็นต้นที่เปิดเผยผ่าน REST API ID สำหรับบริการภายนอกจะต้องเกี่ยวข้องกับ Drupal เช่นเมื่อโหลด "ตลาด" เราต้องการดึงข้อมูลจาก 'market_hours' และ 'คอก' อะไรจะเป็นวิธีที่ดีที่สุดในการแสดงว่าเป็นเนื้อหาแบบอ่านอย่างเดียวใน Drupal ที่ซิงค์เป็นประจำ

ฉันพยายามประเมินด้วยเกณฑ์ต่อไปนี้:

โครงสร้างข้อมูลใน Drupal:

โหนดเทียบกับเอนทิตีที่กำหนดเอง

จำนวนสถานการณ์ที่เกี่ยวข้องกับบริการบนเว็บที่ฉันเคยเห็นใช้เอนทิตีที่กำหนดเอง มันลดความซับซ้อนของ CRUD อย่างไรก็ตามรายการเหล่านี้จะเป็น "เนื้อหา" ที่พวกเขาจะดูต่อสาธารณะ

ที่เก็บข้อมูล (Local vs Remote):

ผมเคยเห็นคู่ของตัวอย่างที่ให้บริการโหลดเป็นหน่วยงานระยะไกลซึ่งโมดูลนี้จะสร้างห้องสมุดสำหรับ: https://drupal.org/project/wsdata สิ่งนี้ฟังดูน่าสนใจที่สุด แต่ยังไม่เห็นกรณีการใช้งานมากมาย นอกจากนี้ยังมีตัวอย่างของรหัสที่กำหนดเอง: https://drupal.org/sandbox/fago/1493180

ซิงค์ข้อมูล:

Feeds กับ Migrate เทียบกับ Guzzle เทียบกับ 'Web Service Client' กับ 'Web Services Data'

มีตัวเลือกมากมาย ฟีดสนับสนุนเอนทิตีในขณะนี้ การย้ายข้อมูลดูเหมือนจะสะอาดกว่าฟีดโดยเฉพาะอย่างยิ่งสำหรับสถานการณ์ที่กำหนดเอง ฉันเคยเห็นคนใช้ไคลเอนต์ guzzle เพื่อซิงค์กับบริการระยะไกล: http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ckan.drush Inc ฉันยังสังเกตเห็นโมดูล WS Client https://drupal.org/project/wsclientให้ตัวเลือกที่สร้างขึ้นโดยเฉพาะเป็นไคลเอนต์ที่เหลือ ข้อมูลบริการเว็บโหลดโดยตรงจากบริการและแคชไว้ในเครื่อง

ขอบคุณสำหรับความคิดใด ๆ

1. จัดรูปแบบคำถามใหม่

ตัวอย่างของคุณแนะนำว่าข้อมูลจะอ่านได้เฉพาะฝั่ง Drupal เท่านั้นโดยการซิงค์ทางเดียวเท่านั้น ฉันคิดว่านี่เป็นปัจจัยที่สำคัญที่สุดในการพิจารณาที่นี่เพราะเหตุใดโซลูชันที่คุณใช้จะแตกต่างจากที่เก็บข้อมูลระยะไกลการซิงค์และการแคชในท้องถิ่น - แม้ว่าการแคชในท้องถิ่นจะกลายเป็นเอนทิตีในฐานข้อมูล Drupal

ดังนั้นคำถามแทนที่จะเป็น "local storage vs remote storage" จะเป็นอย่างไร:

• คุณควรแคชข้อมูลในเครื่องเลย
• คุณควรแคชข้อมูลเป็นเอนทิตีที่แท้จริงและใช้ Feeds (หรือคล้ายกัน) เพื่อซิงโครไนซ์ข้อมูลอย่างสม่ำเสมอ หรือ
• คุณควรใช้โมดูลที่สร้างขึ้นเองที่ให้การซิงค์และการแคช

บทความที่คุณอาจสนใจอยู่ใน " Remote Entities in Drupal 7 "

2. การแคชข้อมูล

โดยทั่วไปการแคชข้อมูลเป็นความคิดที่ดี:

• คุณได้รับการคุ้มครองจากบริการอื่นหรือการหมดเวลาในการเชื่อมต่อ

• การมีข้อมูลของคุณอยู่ในฐานข้อมูล Drupal จะช่วยให้การดำเนินงานรวดเร็วขึ้น

• การมีข้อมูลของคุณอยู่ในฐานข้อมูล Drupal จะหมายความว่าคุณมีแนวโน้มที่จะได้รับการรวมเข้ากับโมดูลอื่น ๆ เช่น Views (แม้ว่าจะไม่รับประกัน)

ข้อได้เปรียบเพียงข้อเดียวของการไม่แคชข้อมูลคือคุณไม่เคยได้รับข้อมูลเก่าซึ่งในบางกรณีเป็นที่นิยมมากกว่า - บางครั้งมันจะดีกว่าที่จะไม่แสดงข้อมูลใด ๆ มากกว่าข้อมูลเก่า ฉันไม่เห็นว่านี่เป็นประโยชน์ในตัวอย่างที่คุณให้ดังนั้นฉันจะเน้นคำตอบนี้ในการแก้ปัญหาที่เกี่ยวข้องกับแคชในท้องถิ่น

3. หน่วยงานท้องถิ่น + ซิงค์

หากคุณเลือกตัวเลือกที่จะมีหน่วยงานท้องถิ่นและทำให้ข้อมูลตรงกันด้วยตนเองเราจะกลับมาที่คำถามดั้งเดิมของคุณ:

• คุณควรใช้โหนดหรือเอนทิตีที่กำหนดเอง;

• โมดูลใดดีที่สุดสำหรับการซิงค์

3.1 โหนดเทียบกับเอนทิตีที่กำหนดเอง

• คำจำกัดความของโหนดคืออะไรที่ค่อนข้างเปิด หน้าเอกสารบนโหนดแสดงให้เห็นว่ามีโหนด "โพสต์" ที่มี "เก็บไว้" บนเว็บไซต์ของคุณ - ทั้งที่นำไปใช้กับข้อมูลของคุณ

• ในฐานะนักพัฒนา Drupal ฉันคาดหวังว่าถ้ามีบางอย่างเป็นโหนดฉันควรจะสามารถจัดการมันบนไซต์ได้

• ในฐานะผู้ใช้ Drupal ฉันก็คาดหวังว่าโหนดนั้นจะสามารถแก้ไขได้

• ปัญหา Drupal 8 นี้https://drupal.org/node/2019031แสดงให้เห็นว่าแนวคิดของ "อ่านอย่างเดียว" เป็นสิ่งที่จะนำไปใช้ในระดับเอนทิตีแทนที่จะเป็นระดับบันเดิล หากสิ่งนี้ได้รับการดำเนินการคุณจะได้รับประโยชน์จากการลงเส้นทางนี้

ในการสรุป: ข้อมูลของคุณกำลังอ่านอย่างเดียวและจัดเก็บจากระยะไกลคุณควรใช้ประเภทนิติบุคคลที่กำหนดเองเพื่อแสดงข้อมูลของคุณ

3.2 การซิงค์

สำหรับส่วนที่สองสองโมดูลหลักนี้จะเป็นคุณแนะนำ, ฟีดและโยกย้าย

ความแตกต่างระหว่างฟีดและการโยกย้ายคือฟีดคือบิลด์สำหรับการนำเข้าเนื้อหาตามปกติในขณะที่โอนย้ายคือบิลด์สำหรับการย้ายพอร์ตเนื้อหาแบบครั้งเดียวจากที่หนึ่งไปอีกที่หนึ่ง การโอนย้ายจะสนับสนุนการอัปเดตข้อมูลที่มีอยู่อย่างไรก็ตามเนื่องจากโมดูลทั้งสองได้รับการสนับสนุนเป็นอย่างดีทำให้มีความเหมาะสมที่จะใช้โมดูลที่สร้างขึ้นสำหรับงานในมือ - ฟีดเป็นการจับคู่ที่ดีกว่า

หลังจากใช้โมดูลทั้งสองตัวเอง (ฟีดสำหรับการซิงค์การโอนย้ายสำหรับการโอนย้าย) ฉันไม่พบฟีดที่จะยุ่งกว่าการโยกย้าย การย้ายข้อมูลจำเป็นต้องใช้รหัสที่กำหนดเองมากขึ้นในประสบการณ์ของฉันแม้ว่าการย้ายทั้งไซต์จะซับซ้อนกว่าการนำเข้าเนื้อหาประเภทเดียวดังนั้นจึงเป็นการยากที่จะเปรียบเทียบ

4. โมดูลที่กำหนดเองสำหรับการจัดเก็บข้อมูลระยะไกลซิงค์ + แคช

มีโมดูลจำนวนมากที่สามารถช่วยเหลืองานนี้ได้

คุณกล่าวถึงเว็บบริการข้อมูลโมดูลและอื่น ๆ ได้กล่าวถึงโมดูลข้อมูล ตัวเลือกที่จะต้องพิจารณาอีกเป็นระยะไกลโมดูล Entity API โปรดทราบว่าหนึ่งเดียวที่ฉันมีประสบการณ์ด้วยคือโมดูลข้อมูล

• โมดูลข้อมูลบริการทางเว็บยังไม่มีรีลีส - ซึ่งอาจระบุว่ารหัสยังไม่เสถียร API อาจมีการเปลี่ยนแปลงและอื่น ๆ มันไม่สนับสนุนการค้นหาฟิลด์ของเอนทิตี (ตามหน้าโปรเจ็กต์) และการเรียกดูอย่างรวดเร็วของที่เก็บรหัสแสดงว่าไม่มีหลักฐานว่ามีการสนับสนุนของวิวดังนั้นคุณจะไม่สามารถใช้ Views เพื่อแสดงเอนทิตีของคุณ

• ในโมดูลของฉัน Data นั้นให้ความสำคัญกับประสบการณ์มากกว่าของฉันต่อผู้ที่ไม่ใช่นักพัฒนาที่มีข้อมูลในตารางและต้องการที่จะเปิดเผยให้ดู ฉันพบว่ารุ่น Drupal 6 ค่อนข้างน่าหงุดหงิดที่จะใช้ - แม้ว่ามันอาจจะเปลี่ยนไปตั้งแต่นั้นมา

• โมดูล Remote Entity API ฟังดูมีแนวโน้มมาก - รองรับการดึงและแคชของเอนทิตีระยะไกลและมีการสนับสนุน Views มันมีเฉพาะในรุ่นอัลฟ่าเท่านั้นดังนั้น API อาจยังเปลี่ยนแปลงได้ จากภาพรวมในครั้งแรกดูเหมือนว่าจะไม่ได้รับการสนับสนุน Entity Field Query และรองรับบริการระยะไกลประเภทหนึ่งเท่านั้นดังนั้นคุณจะต้องใช้งานของคุณเอง

ข้อสรุป

เนื่องจากไม่มีโมดูลหน่วยเก็บข้อมูลระยะไกลที่สนับสนุน Entity Field Queries การใช้เอนทิตี + ฟีดที่แท้จริงคือโซลูชันที่จะช่วยให้คุณทำงานร่วมกับเว็บไซต์ Drupal ได้ดีที่สุด

หากการสนับสนุน Views นั้นเพียงพอและคุณไม่กังวลเกี่ยวกับการรวมที่เป็นไปได้กับโมดูลอื่น ๆ ผ่าน Entity Field Queries ดังนั้นการใช้ Remote Entity API อาจเป็นหนทางไป - คุณจะต้องใช้อินเทอร์เฟซระยะไกลของคุณเอง

หากคุณต้องการมุมมองกฎโทเค็นตะขอตะขอค้นหา api และการรวมระบบที่แข็งแกร่งอย่างแน่นอนในความคิดของฉันพวกเขาไม่สามารถพิจารณาโหนด แต่พวกเขาจะต้องเป็นหน่วยงานที่กำหนดเองที่มี idiosyncrasy ของพวกเขาเอง "รหัสภายนอก" ความสัมพันธ์และด้วยการดึงข้อมูลการโทรถูกห่อหุ้มใน "คุณสมบัติเอนทิตี" ในที่สุดสิ่งที่เครื่องมือที่คุณเลือกสำหรับการซิงค์ข้อมูลฉันจะประมวลผลด้วยคิว cron

หากคุณต้องการดึงข้อมูลและเปิดเผยข้อมูลอย่างตรงเวลาฉันคิดว่าทางเลือกที่ดีกว่าคือสร้างคลาสอินเตอร์เฟสสำหรับดึงข้อมูลภายนอกและใช้อินเทอร์เฟซนี้กับคลาสที่ดึงข้อมูลจากโครงสร้าง "ตลาดเกษตรกร" ของคุณ

ความนับถือ

มีField Storage APIซึ่งช่วยให้สามารถจัดเก็บข้อมูลส่วนหลังแบบเสียบได้นอกเหนือจากเอนจิ้นฐานข้อมูลเริ่มต้น