Каков наиболее устойчивый способ получения совокупной информации по полям?

EntityFieldQuery не предназначен для использования агрегатных функций (SUM, AVG и т. Д.) Над полевыми данными, поскольку он не зависит от SQL. Тем не менее, такие операции на законных основаниях должны проводиться время от времени. В соответствии с функцией SQL с EntityFieldQuery и особенно с EntityFieldQuery и с тем, как использовать агрегатные функции SUM, ARG и MAX , необходимо использовать запросы SQL, и этот подход лучше всего подходит для моего варианта использования. Вчера я разговаривал с @chx, и он рекомендовал использовать пару внутренних функций для поиска имени поля и имени столбца. Мне просто интересно, является ли это устойчивым и уместно ли это делать в кодовой базе, которую я мог бы выпустить другим.

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

Вид поле модуль позволяет выставить таблицы поля в качестве базовых таблиц для представлений. Это отличается от Просмотры поведение по умолчанию в том , что базовая таблица представляет собой таблицу поле , а не объект , к которому данные поля затем загружаются из. Например, при выборе узла в качестве базовой таблицы вы можете добавить поля, но основной (базовая таблица) в запросе по-прежнему является узлом, который в зависимости от ваших данных может испортить агрегатные функции (то есть отношение многих к одному поля к узлу).

Поле представлений позволяет вам получить прямой доступ к таблицам полей, что означает, что агрегатные функции работают правильно. Кроме того, если вам нужно сделать «интересные» объединения с другими таблицами полей, вы можете полностью контролировать их, используя следующие.

/**
 * Implements hook_views_data_alter().
 */
function mymodule_views_data_alter(&$data) {
  views_field_add_multi_join($data, /* see docs */);
}

Что довольно просто в использовании и позволяет вам затем выполнять агрегатные функции сразу для нескольких таблиц полей. Затем вы можете вручную вызвать представление $view->execute()и извлечь результаты из представления. Есть примеры этого в документации представлений.

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

Может ли это быть сделано в дополнительном модуле для просмотра? Он очень хорошо обрабатывает запросы, и некоторые результаты публикуются с помощью агрегатных функций, например, в действиях, когда контекстные фильтры не работают, где он может использовать все значения по умолчанию и подсчитывать доступные результаты в каждом из них. Функции для запросов должны быть там, но для этого потребуется форма пользовательского интерфейса. Дайте мне знать, если это имеет смысл. Я только начинаю анализировать взгляды и размышляю.