Я видел несколько стратегий для интеграции удаленных структур данных в Drupal. Стратегии, похоже, развивались, поскольку некоторые модули стабилизировались и были испробованы варианты использования.

Представьте, что у нас есть структура данных «Рынки фермеров», которая представлена ​​рядом типов данных (market, market_hours, vender, stall, product) и т. Д., Которые предоставляются через REST API. Идентификаторы для внешнего сервиса должны быть связаны в Drupal, то есть при загрузке «рынка» мы хотели бы получить данные из «market_hours» и «stall». Что было бы лучшим способом представить это как доступный только для чтения контент в Drupal, который синхронизируется на регулярной основе?

Я пытаюсь оценить это по следующим критериям:

Структуры данных в Drupal:

Узлы против пользовательских объектов

В ряде сценариев с участием веб-сервисов, которые я видел, используются пользовательские объекты. Это упрощает операции CRUD. Однако эти элементы будут «содержательными» в том смысле, что их можно будет просмотреть публично.

Хранилище (локальное или удаленное):

Я видел пару примеров, когда сервисы загружаются как удаленные объекты, для которых этот модуль создает библиотеку: https://drupal.org/project/wsdata . Это звучит наиболее привлекательно, но не видел много вариантов использования. Там также примеры пользовательского кода: https://drupal.org/sandbox/fago/1493180

Синхронизация данных:

Feeds vs Migrate vs Guzzle vs «Клиент веб-службы» против «Данные веб-сервисов»

Есть несколько вариантов. Feeds теперь поддерживает сущности. Миграция кажется намного чище, чем каналы, особенно для пользовательских сценариев. Я также видел людей, использующих клиентское приложение для захвата синхронизации с удаленными службами: 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 будет означать, что вы с большей вероятностью получите интеграцию с другими модулями, такими как Views (хотя это не гарантируется).

Единственное преимущество отсутствия кэширования данных состоит в том, что вы никогда не получите устаревшие данные, что в некоторых случаях предпочтительнее - иногда предпочтительнее не отображать данные, а не устаревшие данные. Я не рассматриваю это как преимущество в приведенном вами примере, поэтому я сосредоточу этот ответ на решении, которое включает локальное кэширование.

3. Локальные объекты + Синхронизация

Если вы выберете локальные объекты и синхронизируете их самостоятельно, мы вернемся к вашим первоначальным вопросам:

• Если вы используете узлы или пользовательские объекты;

• Какой модуль лучше всего подходит для синхронизации.

3.1 Узлы против пользовательских объектов

• Определение того, что именно является узлом, является достаточно открытым. Страница документации по узлам предполагает, что узлы «публикуют», которые «хранятся» на вашем сайте - ни один из них не применим к вашим данным;

• Как разработчик Drupal, я ожидал бы, что если что-то будет узлом, я смогу манипулировать им на самом сайте;

• Как пользователь Drupal, я бы также ожидал, что узлы можно редактировать;

• В этом выпуске Drupal 8, https://drupal.org/node/2019031, предполагается, что концепция «только для чтения» применима на уровне сущностей, а не на уровне пакетов. Если это когда-либо будет реализовано, вы выиграете, пройдя этот путь.

Подводя итог: ваши данные доступны только для чтения и хранятся удаленно, поэтому имеет больше смысла использовать пользовательский тип объекта для представления ваших данных.

3.2 Синхронизация

Для второй части, как вы предлагаете, два основных модуля для этого - Feeds и Migrate .

Разница между Feeds и Migrate заключается в том, что Feeds предназначен для регулярного импорта контента, а Migrate - для одноразового переноса контента из одного места в другое. Migrate поддерживает обновление существующих данных, однако, учитывая, что оба модуля хорошо поддерживаются, имеет смысл использовать модуль, созданный для поставленной задачи, - Feeds - лучшее соответствие.

Используя оба модуля самостоятельно (каналы для синхронизации, миграция для миграции), я не нахожу каналы более грязными, чем миграция. По моему опыту, для миграции требовалось больше пользовательского кода, хотя миграция целых сайтов сложнее, чем импорт отдельных типов контента, поэтому сравнивать сложно.

4. Пользовательский модуль для удаленного хранения, синхронизации + кеширования

Есть ряд модулей, которые могут помочь с этой задачей.

Вы упомянули модуль данных веб-служб , а другие упомянули модуль данных . Другой вариант, который стоит рассмотреть, - это модуль API удаленного объекта . Обратите внимание, что только один из тех, с кем у меня есть опыт, это модуль данных.

• У модуля данных веб-сервисов еще нет выпуска - это может указывать на то, что код еще не стабилен, API может измениться и так далее. Он не поддерживает запросы полей сущностей (в соответствии со страницей проекта), и быстрый просмотр хранилища кода не показывает никаких доказательств того, что у него есть поддержка Views - поэтому вы не сможете использовать Views для отображения ваших сущностей;

• По моему опыту, модуль данных более ориентирован на тех, кто не является разработчиком, у которого есть данные в таблице, и которые хотят представить их для просмотра. Я обнаружил, что версия Drupal 6 довольно разочаровывает, хотя с тех пор она могла измениться;

• Модуль Remote Entity API звучит довольно многообещающе - он поддерживает выборку и кэширование удаленных объектов, а также имеет поддержку Views. Это только на альфа-версии - так что API все еще может измениться. На первый взгляд кажется, что он не поддерживает Entity Field Query, а поддерживает только один тип удаленного сервиса, поэтому вам придется реализовать свой собственный.

Вывод

Учитывая, что ни один из модулей удаленного хранения не поддерживает Entity Field Queries, использование реальных сущностей + фиды - это решение, которое обеспечит вам наилучшую интеграцию с вашим сайтом Drupal.

Если поддержки Views достаточно, и вы не беспокоитесь о потенциальной интеграции с другими модулями через Entity Field Queries, тогда использование Remote Entity API может оказаться подходящим вариантом - вам, однако, потребуется реализовать собственный удаленный интерфейс.

Если вам нужны представления, правила, токены, перехватчики cruds, API-интерфейсы поиска и определенно сильная системная интеграция, на мой взгляд, они не могут рассматриваться как узлы, но они должны быть пользовательскими объектами со своей собственной особенностью, хранящей в базе данных «идентификатор объекта» и отношение "внешний идентификатор" и с вызовами извлечения информации, инкапсулированными в "свойствах сущности". Наконец, какой бы инструмент вы ни выбрали для синхронизации данных, я обработал бы его cron Queues.

Если вам просто нужно извлекать и представлять данные пунктуально, я думаю, что лучшим выбором было бы создание класса Interface для извлечения внешних данных и реализация этого интерфейса с классом, который извлекает информацию из вашей структуры "Farmers Markets".

С уважением

Есть API-интерфейс Field Storage , который позволяет подключаемым сторонним ресурсам хранения отличаться от ядра базы данных по умолчанию.