Optimise Config EntityQueries in case there are conditions on the 'id'

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Query.php
@@ -124,4 +117,54 @@ public function execute() {
+    // If there are conditions on the config id, we can narrow the list of

This probably should be "config ID" to match the other uses in all caps.

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Query.php
@@ -124,4 +117,54 @@ public function execute() {
+        if ($condition['field'] == $entity_info['entity_keys']['id']) {

Sorry for my ignorance, but when is this true? I have not figured out how to properly debug this patch.

Something like this should allow you to test it:

$ids = Drupal::entityQuery('field_entity')
  ->condition('id', 'node.body')
  ->execute();

That's of course not a very useful example, but it could for example be combined with an additional condition to only load those with a given value in another property.

What about supporting STARTS_WITH as well? That could be used to e.g. load all fields of a given entity type or instances of a specific bundle in a fairly performant way (cached list query + cached getMultiple()).

Reroll after #2005716: Promote EntityType to a domain object. (I still plan to look at this one more closely.)

And now this should fix the new code, too :)

I would say this patch is a definite improvement. I created a simple "Hello World" module that includes this call to Query::execute():

    $ids = \Drupal::entityQuery('field_entity')
      ->condition('id', array('node.body'))
      ->execute();

Here is the XHProf Overall Diff Summary with before (left/52caece0e37bb) and after (right/52caebbc2e590):

+          $operator = $condition['operator'] ?: (is_array($condition['value']) ? 'IN' : '=');
+          if ($operator == '=' || $operator == 'IN') {
+            $ids = is_array($condition['value']) ? $condition['value'] : array($condition['value']);
+            // We can stop at the first condition on ID. In the (weird) case
+            // where other conditions additionally restrict IDs, results will
+            // be eliminated when the conditions are checked on the loaded
+            // records.
+            break;
+          }

This code path could have been split into two code paths via if + elseif, since one of them operates on an array and the other one operates on a string. The single code path makes it hard to read the code.

That would also allow us to be a bit more explicit about the IN code path. That is, because I'm not sure whether this automatic assumption of IN is fully compatible with the discussion in #2161943: Throw a helpful exception for empty IN conditions in Database\Query\Condition

Thanks!

Not sure why the additional is_string(field) condition is needed, but it certainly can't hurt.

Committed ddfbbf5 and pushed to 8.x. Thanks!