Qual è il modo più sostenibile per ottenere informazioni aggregate sui campi?

EntityFieldQuery non è destinato all'uso per eseguire funzioni aggregate (SUM, AVG, ecc.) Su dati di campo poiché è indipendente da SQL. Detto questo, tali operazioni devono legittimamente essere eseguite di volta in volta. Secondo la funzione SQL con EntityFieldQuery e in particolare EntityFieldQuery e come utilizzare le funzioni di aggregazione SUM, ARG e MAX , è necessario utilizzare le query SQL e questo approccio si adatta meglio al mio caso d'uso. Ieri ho parlato con @chx e mi ha consigliato di utilizzare un paio di funzioni interne per trovare il nome del campo e il nome della colonna. Mi chiedo solo se questo è sostenibile e se è appropriato fare in una base di codice che potrei rilasciare ad altri.

Se è il modo migliore, allora è il modo migliore. Non voglio farlo prima di essere assolutamente sicuro perché mi sembra disordinato.

Il modulo Campo vista consente di esporre le tabelle dei campi come tabelle di base alle viste. Ciò differisce dal comportamento predefinito di Views in quanto la tabella di base è la tabella di campo e non un'entità da cui vengono quindi caricati i dati del campo. Ad esempio, quando si seleziona il nodo come tabella di base è quindi possibile aggiungere campi, ma la principale (tabella di base) nella query è ancora nodo che, a seconda dei dati, può rovinare le funzioni aggregate (ovvero una relazione molti-a-uno di alcuni campi al nodo).

Il campo Visualizzazioni consente di accedere direttamente alle tabelle dei campi, il che significa che le funzioni di aggregazione funzionano correttamente. Inoltre, se è necessario eseguire join "interessanti" ad altre tabelle di campi, è possibile controllarli completamente utilizzando quanto segue.

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

Che è abbastanza semplice da usare e ti consente quindi di eseguire funzioni aggregate su più tabelle di campo contemporaneamente. È quindi possibile richiamare manualmente una vista $view->execute()ed estrarre i risultati dalla vista. Ci sono esempi di ciò nella documentazione delle viste.

I vantaggi di questo approccio rispetto a EntityFieldQuery sono la possibilità di gestire il processo in Views (che quasi tutti utilizzeranno già) e consentirgli di eseguire la creazione di query fisiche in modo meno diretto, contribuendo a elevare possibili rotture lungo la strada. Inoltre molte volte vorrai visualizzare tali dati aggregati su una schermata di amministrazione che puoi quindi utilizzare la vista per fornire sia una visualizzazione che accedere ai risultati nel codice per scopi aggiuntivi.

Questo potrebbe essere fatto in un modulo aggiuntivo per le viste? Gestisce le query molto bene e alcuni risultati sono pubblicati con funzioni aggregate come nelle azioni in cui i filtri contestuali falliscono dove può essere impostato su tutti i valori e dare conteggi sui risultati disponibili in ciascuno. Le funzioni per le query dovrebbero essere presenti ma sarebbe necessario un modulo di interfaccia utente. Fammi sapere se questo ha senso. Sto solo cominciando a sezionare le opinioni e sto speculando.