Widziałem wiele strategii integracji zdalnych struktur danych w Drupal. Wydaje się, że strategie ewoluowały, ponieważ niektóre moduły ustabilizowały się i wypróbowano przypadki użycia.
Wyobraź sobie, że mamy strukturę danych „Rynki rolników”, która jest reprezentowana przez wiele typów danych (rynek, godziny rynku, sprzedawca, stoisko, produkcja) itp., Które są udostępniane za pośrednictwem interfejsu API REST. Identyfikatory usługi zewnętrznej musiałyby odnosić się w Drupal, tzn. Podczas ładowania „rynku” chcielibyśmy pobrać dane z „godzin_rynku” i „przeciągnięcia”. Jaki byłby najlepszy sposób na przedstawienie tego jako treści tylko do odczytu w Drupal, która jest regularnie synchronizowana?
Próbuję to ocenić, stosując następujące kryteria:
Struktury danych w Drupal:
Węzły a jednostki niestandardowe
Wiele scenariuszy dotyczących usług sieciowych, które widziałem, używa niestandardowych encji. Upraszcza operacje CRUD. Te elementy byłyby jednak „treścią”, ponieważ byłyby oglądane publicznie.
Pamięć (lokalna vs zdalna):
Widziałem kilka przykładów, w których usługi są ładowane jako jednostki zdalne, dla których ten moduł tworzy bibliotekę dla: https://drupal.org/project/wsdata . Brzmi to najbardziej atrakcyjnie, ale nie widziałem wielu przypadków użycia. Istnieją również przykłady niestandardowego kodu: https://drupal.org/sandbox/fago/1493180
Synchronizowanie danych:
Kanały vs Migracja vs Guzzle vs „Klient usług sieciowych” vs „Dane usług sieciowych”
Istnieje wiele opcji. Kanały obsługują teraz podmioty. Migracja wydaje się dużo czystsza niż kanały, szczególnie w przypadku niestandardowych scenariuszy. Widziałem też ludzi używających klienta żubra do synchronizacji ze zdalnymi usługami: http://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x:/ckan.drush. inc # l273 . Zauważyłem również, że moduł klienta WS https://drupal.org/project/wsclient zapewnia opcję, która została stworzona specjalnie jako klient spoczynkowy. Usługi sieciowe Dane ładują się bezpośrednio z usługi i buforują je lokalnie.
Dzięki za wszelkie przemyślenia.
Odpowiedzi:
1. Przeformułowanie pytania
Twój przykład sugeruje, że dane są odczytywane tylko po stronie Drupala, z synchronizacją tylko w jedną stronę. Myślę, że jest to najważniejszy czynnik, który należy wziąć pod uwagę, ponieważ w efekcie każde wdrożone rozwiązanie będzie wariantem zdalnego przechowywania, synchronizacji i lokalnego buforowania - nawet jeśli lokalne buforowanie zakończy się jako jednostki w bazie danych Drupal.
Zatem pytanie, zamiast być „pamięcią lokalną a pamięcią zdalną”, brzmi:
Artykuł, który może Cię zainteresować, znajduje się w „ Zdalnych jednostkach w Drupal 7 ”.
2. Buforowanie danych
Ogólnie buforowanie danych jest dobrym pomysłem:
Jesteś chroniony przed przerwami w działaniu innych usług lub przekroczeniem limitu czasu połączenia;
Obecność danych w bazie danych Drupal przyspieszy operacje;
Obecność danych w bazie danych Drupal oznacza, że istnieje większe prawdopodobieństwo integracji z innymi modułami, takimi jak Widoki (choć nie jest to gwarantowane).
Jedyną zaletą braku buforowania danych jest to, że nigdy nie dostajesz przestarzałych danych, co w niektórych przypadkach jest lepsze - czasami lepiej nie wyświetlać żadnych danych niż nieaktualnych danych. Nie widzę tego w podanym przez ciebie przykładzie, dlatego skoncentruję się na odpowiedzi obejmującej lokalne buforowanie.
3. Podmioty lokalne + Synchronizacja
Jeśli wybierzesz opcję posiadania lokalnych podmiotów i samodzielnego ich synchronizowania, wrócimy do twoich oryginalnych pytań:
Jeśli używasz węzłów lub encji niestandardowych;
Który moduł najlepiej nadaje się do synchronizacji.
3.1 Węzły a podmioty niestandardowe
Definicja tego, czym dokładnie jest węzeł, jest dość otwarta. Strona dokumentacji w węzłach sugeruje, że węzły „publikują”, które są „przechowywane” w Twojej witrynie - żaden z nich nie dotyczy twoich danych;
Jako programista Drupal spodziewałbym się, że jeśli coś jest węzłem, powinienem być w stanie manipulować nim na samej stronie;
Jako użytkownik Drupala podobnie oczekiwałbym, że węzły można edytować;
Ten numer Drupala 8 https://drupal.org/node/2019031 sugeruje, że pojęcie „tylko do odczytu” to takie, które miałoby zastosowanie na poziomie jednostki, a nie na poziomie pakietu. Jeśli to kiedykolwiek zostanie wdrożone, skorzystasz z tego, idąc tą drogą.
Podsumowując: dane są tylko do odczytu i przechowywane zdalnie , bardziej sensowne jest użycie niestandardowego typu encji do reprezentowania danych.
3.2 Synchronizacja
W drugiej części dwoma głównymi modułami są, jak sugerujesz, kanały i migracja .
Różnica między Kanałami a Migracją polega na tym, że Kanały są budowane do regularnego importowania treści, podczas gdy Migracja jest przeznaczona do jednorazowego przenoszenia treści z jednego miejsca do drugiego. Migracja obsługuje aktualizację istniejących danych, jednak biorąc pod uwagę, że oba moduły są dobrze obsługiwane, sensowniej jest użyć modułu, który został zbudowany dla danego zadania - Kanały lepiej pasują.
Sam korzystałem z obu modułów (Kanały do synchronizacji, Migracja do migracji). Nie uważam, aby Kanały były bardziej niechlujne niż Migracja. Z mojego doświadczenia wynika, że migracja wymagała więcej niestandardowego kodu, chociaż migracja całych witryn jest bardziej złożona niż importowanie pojedynczych typów treści, więc trudno je porównać.
4. Niestandardowy moduł do zdalnego przechowywania, synchronizacji + buforowania
Istnieje wiele modułów, które mogą pomóc w tym zadaniu.
Wspomniałeś o module danych usług WWW , a inni wspomnieli o module danych . Inną opcją do rozważenia jest moduł API Remote Entity . Pamiętaj, że jedyną z nich, z którą mam doświadczenie, jest moduł danych.
Moduł danych usług WWW nie ma jeszcze wydania - co może wskazywać, że kod nie jest jeszcze stabilny, interfejs API może ulec zmianie i tak dalej. Nie obsługuje zapytań o pola encji (zgodnie ze stroną projektu), a szybkie przeglądanie repozytorium kodu nie pokazuje, że ma on obsługę widoków - więc nie można używać widoków do wyświetlania swoich bytów;
Z mojego doświadczenia wynika, że moduł danych jest bardziej zorientowany na programistów, którzy mają dane w tabeli i chcą je wystawiać na widoki. Uznałem, że korzystanie z wersji Drupal 6 jest dość frustrujące - choć od tego czasu mogło się to zmienić;
Moduł interfejsu API Remote Entity brzmi dość obiecująco - obsługuje pobieranie i buforowanie zdalnych jednostek oraz obsługę widoków. To jest tylko w wersji alfa - więc API może się jeszcze zmienić. Na pierwszy rzut oka wydaje się, że nie obsługuje on również Entity Field Query, a obsługuje tylko jeden typ zdalnej usługi, więc trzeba będzie wdrożyć własną.
Wniosek
Biorąc pod uwagę, że żaden ze zdalnych modułów pamięci nie obsługuje zapytań o pola encji, użycie rzeczywistych encji + kanałów jest rozwiązaniem, które zapewni najlepszą integrację z witryną Drupal.
Jeśli obsługa widoków jest wystarczająca i nie martwisz się potencjalną integracją z innymi modułami za pomocą zapytań Entity Field, skorzystaj z interfejsu Remote Entity API - możesz jednak zaimplementować własny interfejs zdalny.
źródło
Jeśli potrzebujesz widoków, reguł, tokenów, cruds hooków, interfejsu API wyszukiwania i zdecydowanie silnej integracji systemu, moim zdaniem, nie można ich uważać za węzły, ale muszą to być niestandardowe byty z własną idiosynkrazją przechowującą w bazie danych „identyfikator jednostki” i relacja „identyfikator zewnętrzny” oraz wywołania informacji o wyszukiwaniu zawarte w „właściwościach jednostki”. Wreszcie, bez względu na to, jakie narzędzie wybierzesz do synchronizacji danych, przetworzę je za pomocą kolejek cron.
Jeśli potrzebujesz tylko punktualnego pobierania i ujawniania danych, myślę, że lepszym wyborem byłoby utworzenie klasy Interface do pobierania danych zewnętrznych i zaimplementowanie tego interfejsu za pomocą klasy, która pobierze informacje ze struktury „Farmers Markets”.
pozdrowienia
źródło
Istnieje interfejs Field Storage API , który pozwala na podłączanie zaplecza pamięci innego niż domyślny silnik bazy danych.
źródło