When #1138542: Add support for custom Views handlers or something similar is implemented, people may define their own custom view handlers. However, when creating such a handler for a EntityFieldQuery the querying possibilities are limited. Sometimes module developers know for sure that their entities will be stored in an SQL database so why not provide them full SQL capabilities? The following patch lets you execute methods on query objects by registering them to the query metadata system.
Below is an example of how to use this for filtering out NULL values:
/**
* Custom filter handler for views to filter for, or filer out 'empty' values.
*/
class example_handler_filter_has_value extends views_handler_filter_boolean_operator {
function query() {
if (empty($this->value)) {
$this->query->query->addTag('meta_sql');
$this->query->query->addMetaData('meta_sql', array('isNull' => array('example_field')));
}
else {
$this->query->query->addTag('meta_sql');
$this->query->query->addMetaData('meta_sql', array('isNotNull' => array('example_field')));
}
}
}
Since it is just a small patch i believe adding it to efq_views will be beter than making it a separate contrib module.
Comments
Comment #1
xatoo commentedAnd the patch of course...
Comment #2
bojanz commentedI discussed this with chx yesterday and I don't believe this is something efq_views should do.
The whole point of EFQ is abstraction, and supporting multiple backends.
People who use efq_views (all five of them) are either using an alternative field storage backend, or are planning to switch to one at a later point.
Assuming SQL at any point makes no sense in that case. That's what Views proper does, so if anyone wants to assume an SQL backend, he can easily just use Views, which will always have better SQL support than efq_views could hope to hack in (for example, group by, aggregate functions, etc...)
Comment #3
xatoo commentedI agree with your vision about efq_views being about abstraction
However, I still believe there is need for such functionality. Using an alternative storage backend doesn't imply that that isn't a SQL storage. I doubt whether this patch breaks abstraction. I don't have enough experience with alternative storage to determine that. Is hook_query_alter only called for SQL queries? Otherwise, it could theoretically allow the execution of specific methods on any type of query object.
I am working on a module to store entities in remote databases. If hook_query_alter only gets called for SQL queries, than the only reason to use EFQ is when you want to store entities in remote databases. So, in that case i could better include this with that module. Could you please confirm or clarify this?
Comment #4
bojanz commentedYes, only for SQL.
EFQ has it's own, hook_entity_query_alter();
Though, do note that EFQ in the default case issues an SQL query, so your alter would still get fired.