Drupal Query builder

Question

Я довольно часто использую модуль Views Drupal для сборки SQL, который вставляю в мой код. Он хорошо понимает схему базы данных Drupal.

Есть ли модуль, который дал бы мне эту функциональность, или я могу выделить это из Views?

Answer 1

Было бы здорово, если бы модуль Views был расширен для лучшей поддержки программного использования, но до этого вы, возможно, захотите взглянуть на попытку одного из моих коллег создать нечто похожее на такую ​​вещь: http://github.com/hugowetterberg/query_builder

С этим может быть связана попытка проекта Services по предоставлению данных Views в качестве услуги, усилия, которые мы сейчас выделяем в отдельный модуль: http://drupal.org/node/709100 Может быть, стоит следовать, так как ему понадобятся некоторыеуровень программного доступа к Views.

Другим примером модуля, который осуществляет программный доступ к Views, является Development Seeds Litenode: http://developmentseed.org/blog/2009/feb/4/litenode

Обновление 15/12-2010: EntityFieldQuery в Drupal 7 это почти то же самое, что использование Views для программного создания запросов. Разница заключается в том, что EntityQueryBuilder работает только с сущностями и полями, а также с тем преимуществом, что фактически может создавать запросы к любому типу используемого хранилища полей, например.база данных NoSQL, такая как MongoDB.Пример можно найти здесь: http://drupal4hu.com/node/267

Answer 2

Хотя это не идеальный способ сделать что-то, вы можете получить результаты представления следующим образом:

$view = views_get_view('search');
$view->set_display('main');
$view->set_items_per_page(0);
$view->execute();

$items = array();
foreach ($view->result as $row) {
  $items[] = $row;
}

Таким образом, всякий раз, когда вы изменяете запрос представлений, вам не нужно повторно копировать код. Я согласен с тем, что представления необходимо разделить на API построения запросов и пользовательский интерфейс.

Answer 3

Мне любопытно - почему вы используете Views для построения SQL, а затем не используете Views?

Когда речь идет о более сложных вещах, таких как отношения «многие ко многим», GROUP BY, COUNT, SUM, подзапросы и т. Д., Независимо от того, к чему призывает функция, лучше написать ее самостоятельно (особенно, если модули contrib не поддерживают представления и вам нужно больше чем таблица узлов).

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

Answer 4

Да, я предполагаю, что представления лучше всего знать, какие таблицы используются для текущего поля, поскольку многие модули (и более в представлениях) имеют функции подключения, которые предоставляют некоторую информацию об этом поле, таблице и типе соединения с другими таблицами. ,

Также вы можете прочитать схему таблиц и полей через: http://drupal.org/project/schema