18

Why should I use EntityFieldQuery when I can do the same work with Db_select() to fetch the value.

It would be better if someone can provide an example, not only a link.

4 Answers 4

11

I think the point is that the syntax is much simpler, and the code will be more understandable.

For example, if you want nodes with type my_type that have a field named field_foo with the value $val, with Db_Select, yuoll do something like :

$nids = db_select('node', 'n')
  ->fields('n', array('nid'))
  ->join('field_data_field_foo', 'foo', 'foo.entity_id = n.nid')
  ->condition('n.type', 'my_type')
  ->condition('foo.field_foo_value', $val)
  ->execute()->fetchCol();

Which is much simpler with EntityFieldQuery :

$query = new EntityFieldQuery;
$entities = $query->entityCondition('entity_type', 'node')
  ->entityCondition('bundle', 'my_type')
  ->fieldCondition('field_foo', 'value', $val)
  ->execute();
14

I think that the main reason prefering EntityFieldQuery over db_select is that you don't have to know about the lower-level structure, in other words: how stuff is stored in the database. This improves loose coupling.

1
  • 6
    This is correct, although it goes even further. The field storage is pluggable. The default implementation stores field data in a separate table per field in the database, but it can be replaced, there is for example an implementation which allows to store field data in MongoDB. If you want your code to be portable and not just work on your specific site configuration, you must use EntityFieldQuery.
    – Berdir
    Commented Oct 5, 2011 at 2:51
3

EntityFieldQuery (EFQ) will only return entity IDs. If you want to access entities data, you'll have to call entity_load(), which, among loading the data, will make sure that all underlying stuff you normally do not care about (such as loading fields, calling other modules hooks etc.) are made. Of course, this result in two SQL queries and a lot of overhead, but this is the price to pay for the abstraction.

As for the EFQ syntax being more clear, I think it's much more a question of personal preferences. I, for instance, do not think that EFQ is clearer. Notice that a working db_select() replacement with EFQ must include the return value test and subsequent entity_load() call, and this adds a lot of noise to the code, IMHO:

$query = new EntityFieldQuery();
$entities = $query->entityCondition('entity_type', 'node')
  ->entityCondition('bundle', 'my_type')
  ->fieldCondition('field_foo', 'value', $val)
  ->execute();
if (!empty($entities['node'])) {
  $nodes = entity_load('node', array_keys($entities['node']));
} else {
  $nodes = array();
}

So, answering your question: use EFQ if your entities are full-featured (e.g. are fieldable, can be used by other modules, etc.) and/or you think that its syntax is clearer. If other cases, use may use db_select().

2
  • Not exactly, you can use entity_metadata_wrapper and access only what you need.
    – Kevin
    Commented Mar 29, 2016 at 20:22
  • I fail to see how entity_metadata_wrapper() helps here. You still need to load the entity.
    – flaviovs
    Commented Mar 31, 2016 at 0:35
1

EntityFieldQuery is far more limited than db_select(), so you should have a really good reason to not use db_select() (see bart answer), which is readable enough and far more flexible.

For example, entityFieldQuery use innerJoin to fetch fields. If you need a leftJoin for whatever reason, you're trapped... http://drupal.org/node/1226622

4
  • Well, I would like to know why my anwser had a "-1". yeah, entityFieldQuery is prettier, but less efficient than db_select that is a very nice, robust and complete API... I remove a lot of my entityFieldQuery from my code because it was too limited for specific use cases, think it definitely deserved to be pointed out. Anyway.
    – yann_yinn
    Commented Apr 11, 2013 at 13:54
  • 1
    I think some don't like your answer because it fails to acknowledge how entityFieldQuery is an abstraction layer above different storage methods, which is a cool feature. I work on lots of sites where we know that, say, MySQL will always be the database for x/y/z and we also prefer to write leaner db queries when we need to. I don't find entityFieldQuery to be any prettier than db_select. The 2 comparisons at the top of the page are nearly visually identical. Commented Aug 14, 2013 at 16:57
  • yep, that's why i wrote "see bart answer". Except for this special use-case, db_select will be more efficient and far more flexible.
    – yann_yinn
    Commented Jun 23, 2014 at 14:30
  • I completely agree. Commented Jun 23, 2014 at 19:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.