Ich habe eine Reihe von Strategien zur Integration entfernter Datenstrukturen in Drupal gesehen. Die Strategien haben sich offenbar weiterentwickelt, da sich bestimmte Module stabilisiert und Anwendungsfälle ausprobiert wurden.

Stellen Sie sich vor, wir haben eine Datenstruktur "Farmers Markets", die durch eine Reihe von Datentypen (Markt, Marktstunden, Verkäufer, Stand, Produkt) usw. dargestellt wird, die über eine REST-API verfügbar gemacht werden. Die IDs für den externen Dienst müssten sich in Drupal beziehen, dh beim Laden eines "Marktes" möchten wir Daten aus den 'market_hours' und 'Stall' abrufen. Was wäre der beste Weg, dies als schreibgeschützten Inhalt in Drupal darzustellen, der regelmäßig synchronisiert wird?

Ich versuche dies anhand der folgenden Kriterien zu bewerten:

Datenstrukturen in Drupal:

Knoten gegen benutzerdefinierte Entitäten

In einer Reihe von Szenarien mit Webdiensten wurden benutzerdefinierte Entitäten verwendet. Es vereinfacht die CRUD-Operationen. Diese Elemente wären jedoch "Inhalt", da sie öffentlich angezeigt würden.

Speicher (lokal oder remote):

Ich habe einige Beispiele gesehen, in denen Dienste als Remote-Entitäten geladen werden, für die dieses Modul eine Bibliothek erstellt: https://drupal.org/project/wsdata . Das klingt am ansprechendsten, hat aber nicht viele Anwendungsfälle gesehen. Es gibt auch Beispiele für benutzerdefinierten Code: https://drupal.org/sandbox/fago/1493180

Daten synchronisieren:

Feeds vs Migrate vs Guzzle vs 'Web Service Client' vs 'Web Services Data'

Es gibt eine Reihe von Optionen. Feeds unterstützen jetzt Entitäten. Die Migration scheint viel sauberer als Feeds zu sein, insbesondere für benutzerdefinierte Szenarien. Ich habe auch Leute gesehen, die einen Guzzle-Client verwenden, um die Synchronisierung mit Remote-Diensten durchzuführen: http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ckan.drush. inc # l273 . Ich habe auch festgestellt, dass das WS-Client-Modul https://drupal.org/project/wsclient eine Option bietet, die speziell als Rest-Client erstellt wurde. Webdienste Daten werden direkt von einem Dienst geladen und lokal zwischengespeichert.

Danke für alle Gedanken.

1. Die Frage neu formulieren

In Ihrem Beispiel wird vorgeschlagen, dass die Daten auf der Drupal-Seite schreibgeschützt sind und nur in eine Richtung synchronisiert werden. Ich denke, dies ist der wichtigste Faktor, der hier berücksichtigt werden muss, da jede von Ihnen implementierte Lösung eine Variante von Remotespeicherung, Synchronisierung und lokalem Caching darstellt - selbst wenn das lokale Caching letztendlich Entitäten in der Drupal-Datenbank sind.

Die Frage lautet also, anstatt "lokaler Speicher gegen Remote-Speicher" zu sein:

• Sollten Sie die Daten überhaupt lokal zwischenspeichern;
• Sollten Sie die Daten als tatsächliche Entitäten zwischenspeichern und Feeds (oder ähnliches) verwenden, um die Daten regelmäßig zu synchronisieren; ODER
• Sollten Sie ein maßgeschneidertes Modul verwenden, das die Synchronisierung und das Caching ermöglicht.

Ein Artikel, der Sie interessieren könnte, ist " Remote Entities in Drupal 7 ".

2. Zwischenspeichern der Daten

Im Allgemeinen ist das Zwischenspeichern der Daten eine gute Idee:

• Sie sind vor Ausfällen der anderen Dienste oder Zeitüberschreitungen in der Verbindung geschützt.

• Wenn Ihre Daten in Ihrer Drupal-Datenbank vorhanden sind, wird der Betrieb beschleunigt.

• Wenn Ihre Daten in Ihrer Drupal-Datenbank vorhanden sind, ist die Wahrscheinlichkeit höher, dass Sie in andere Module wie Ansichten integriert werden (dies ist jedoch nicht garantiert).

Der einzige Vorteil, wenn die Daten nicht zwischengespeichert werden, besteht darin, dass Sie niemals veraltete Daten erhalten, was in einigen Fällen vorzuziehen ist. Manchmal ist es vorzuziehen, keine Daten anstelle veralteter Daten anzuzeigen. Ich sehe dies in dem von Ihnen angegebenen Beispiel nicht als Vorteil an, daher werde ich diese Antwort auf eine Lösung konzentrieren, die lokales Caching umfasst.

3. Lokale Entitäten + Synchronisierung

Wenn Sie sich für die Option entscheiden, lokale Entitäten zu haben und diese selbst zu synchronisieren, kehren wir zu Ihren ursprünglichen Fragen zurück:

• Sollten Sie Knoten oder benutzerdefinierte Entitäten verwenden;

• Welches Modul eignet sich am besten für die Synchronisierung?

3.1 Knoten gegen benutzerdefinierte Entitäten

• Die Definition, was genau ein Knoten ist, ist ziemlich offen. Auf der Dokumentationsseite zu Knoten wird vorgeschlagen , dass Knoten "Beiträge" veröffentlichen, die auf Ihrer Site "gespeichert" sind - beides gilt nicht für Ihre Daten.

• Als Drupal-Entwickler würde ich erwarten, dass wenn etwas ein Knoten ist, ich es auf der Site selbst manipulieren kann;

• Als Drupal-Benutzer würde ich ebenfalls erwarten, dass Knoten bearbeitet werden können.

• Diese Drupal 8-Ausgabe https://drupal.org/node/2019031 legt nahe, dass das Konzept "schreibgeschützt" eher auf Entitätsebene als auf Bundle-Ebene gilt. Sollte dies jemals umgesetzt werden, würden Sie davon profitieren, wenn Sie diesen Weg gegangen wären.

Zusammenfassend lässt sich sagen, dass Ihre Daten schreibgeschützt sind und remote gespeichert werden. Es ist sinnvoller, einen benutzerdefinierten Entitätstyp zur Darstellung Ihrer Daten zu verwenden.

3.2 Synchronisieren

Für den zweiten Teil sind die beiden Hauptmodule hierfür, wie Sie vorschlagen, Feeds und Migrate .

Der Unterschied zwischen Feeds und Migrate besteht darin, dass Feeds für den regelmäßigen Import von Inhalten erstellt werden, während Migrate für die einmalige Portierung von Inhalten von einem Ort zum anderen erstellt wird. Migrate unterstützt die Aktualisierung vorhandener Daten. Da jedoch beide Module gut unterstützt werden, ist es sinnvoller, das Modul zu verwenden, das für die jeweilige Aufgabe erstellt wurde. Feeds passen besser zusammen.

Nachdem ich beide Module selbst verwendet habe (Feeds für die Synchronisierung, Migration für die Migration), finde ich Feeds nicht unordentlicher als Migrate. Nach meiner Erfahrung war für die Migration mehr benutzerdefinierter Code erforderlich. Die Migration ganzer Websites ist jedoch komplexer als der Import einzelner Inhaltstypen, sodass ein Vergleich schwierig ist.

4. Benutzerdefiniertes Modul für Remote-Speicher, Synchronisierung + Caching

Es gibt eine Reihe von Modulen, die bei dieser Aufgabe helfen können.

Sie haben das Web Services-Datenmodul erwähnt , und andere haben das Datenmodul erwähnt . Eine weitere zu berücksichtigende Option ist das Remote Entity API-Modul . Beachten Sie, dass das einzige, mit dem ich Erfahrung habe, das Datenmodul ist.

• Das Web Services Data-Modul verfügt noch nicht über eine Version. Dies kann darauf hinweisen, dass der Code noch nicht stabil ist, die API möglicherweise geändert wird usw. Entitätsfeldabfragen werden nicht unterstützt (gemäß der Projektseite), und ein schnelles Durchsuchen des Code-Repositorys zeigt keine Hinweise darauf, dass Ansichten unterstützt werden. Sie können also keine Ansichten zum Anzeigen Ihrer Entitäten verwenden.

• Das Datenmodul richtet sich meiner Erfahrung nach eher an Nicht-Entwickler, die Daten in einer Tabelle haben und diese Ansichten anzeigen möchten. Ich habe festgestellt, dass die Verwendung der Drupal 6-Version ziemlich frustrierend ist - obwohl sich dies seitdem möglicherweise geändert hat.

• Das Remote Entity API-Modul klingt vielversprechend - es unterstützt das Abrufen und Zwischenspeichern von Remote Entities und unterstützt Views. Es ist nur auf Alpha-Version - daher kann sich die API noch ändern. Auf den ersten Blick scheint es auch keine Unterstützung für Entity Field Query zu geben, und es wird nur eine Art von Remote-Service unterstützt, sodass Sie Ihren eigenen implementieren müssten.

Fazit

Da keines der Remotespeichermodule Entitätsfeldabfragen unterstützt, ist die Verwendung tatsächlicher Entitäten + Feeds die Lösung, mit der Sie die beste Integration in Ihre Drupal-Site erzielen.

Wenn die Unterstützung von Ansichten ausreicht und Sie sich keine Sorgen über eine mögliche Integration mit anderen Modulen über Entitätsfeldabfragen machen, ist die Verwendung der Remote-Entitäts-API möglicherweise der richtige Weg. Sie müssten jedoch Ihre eigene Remote-Schnittstelle implementieren.

Wenn Sie Ansichten, Regeln, Token, Cruds-Hooks, Such-APIs und eine definitiv starke Systemintegration benötigen, können diese meiner Meinung nach nicht als Knoten betrachtet werden, sondern müssen benutzerdefinierte Entitäten mit eigener Eigenart sein, die in der Datenbank die "Entitäts-ID" und die "Entitäts-ID" speichern Beziehung "externe ID" und mit den Abrufen von Informationsaufrufen, die in den "Entitätseigenschaften" gekapselt sind. Unabhängig davon, welches Tool Sie zum Synchronisieren von Daten auswählen, würde ich es schließlich mit Cron-Warteschlangen verarbeiten.

Wenn Sie Daten nur pünktlich abrufen und verfügbar machen müssen, ist es meiner Meinung nach besser, eine Schnittstellenklasse zum Abrufen externer Daten zu erstellen und diese Schnittstelle mit einer Klasse zu implementieren, die die Informationen aus Ihrer "Farmers Markets" -Struktur abruft.

Grüße

Es gibt die Field Storage-API , die andere steckbare Speicher-Backends als das Standard-Datenbankmodul ermöglicht.