Qual é a maneira mais sustentável de obter informações agregadas nos campos?

O EntityFieldQuery não se destina a ser usado para executar funções agregadas (SUM, AVG, etc.) em dados de campo porque é independente de SQL. Dito isto, essas operações precisam legitimamente ser executadas de tempos em tempos. De acordo com a função SQL com EntityFieldQuery e especialmente EntityFieldQuery e como usar as funções agregadas SUM, ARG e MAX , as consultas SQL precisam ser usadas, e essa abordagem se encaixa melhor no meu caso de uso. Eu estava falando com o @chx ontem e ele recomendou o uso de algumas funções internas para encontrar o nome do campo e o nome da coluna. Só estou me perguntando se isso é sustentável e se é apropriado fazer em uma base de código que eu possa lançar para outros.

Se é o melhor caminho, então é o melhor caminho. Só não quero fazer isso antes de ter certeza absoluta, porque parece uma bagunça.

O módulo de campo Exibir permite expor as tabelas de campos como tabelas base às visualizações. Isso difere do comportamento padrão do Views, pois a tabela base é a tabela de campos e não uma entidade da qual os dados do campo são carregados. Por exemplo, ao selecionar o nó como uma tabela base, você pode adicionar campos, mas a principal (tabela base) da consulta ainda é um nó que, dependendo dos seus dados, pode estragar as funções agregadas (também conhecido como um relacionamento muitos-para-um de alguns campos para o nó).

O campo Views permite o acesso direto às tabelas de campos, o que significa que as funções agregadas funcionam corretamente. Além disso, se você precisar fazer associações "interessantes" a outras tabelas de campo, poderá controlá-las completamente usando o seguinte.

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

O que é bastante simples de usar e permite que você execute funções agregadas em várias tabelas de campo ao mesmo tempo. Em seguida, você pode invocar uma vista manualmente $view->execute()e retirar os resultados dela. Existem exemplos disso na documentação das visualizações.

Os benefícios dessa abordagem sobre o EntityFieldQuery é que você pode gerenciar o processo no Views (que quase todo mundo já estará usando) e permitir que ele execute a criação de consultas físicas de maneira menos direta, o que ajuda a elevar possíveis avarias no caminho. Além disso, muitas vezes você desejará exibir esses dados agregados em uma tela de administrador, que poderá usar a exibição para fornecer uma exibição e acessar os resultados no código para fins adicionais.

Isso poderia ser feito em um módulo complementar para visualizações? Ele lida com as consultas muito bem e alguns resultados são publicados com funções agregadas, como em ações quando os filtros contextuais falham, onde é possível padronizar todos os valores e fornecer contagens dos resultados disponíveis em cada um. As funções para as consultas devem estar lá, mas seria necessário um formulário de interface do usuário. Deixe-me saber se isso faz sentido. Estou apenas começando a dissecar pontos de vista e a especular.