We could take the single - value fields and grep for them in the active directory in the relevant named files. If grep is not working then load 'em all and memory-query them, there's hardly anything else we can do to them.

This is almost a bug because right now there's no way without loading all the views to list them by a specific tag and that can be a serious regression if you happen to have a thousand or so Views.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

I like the idea, because loading all configuration entities on listings is a problem in general but not a regression.

The question is whether we should fallback to memory query or tell people: Please install grep.
Another question, are we sure that using grep is a relyable way to query, if grep might be slightly different between installed versions/implementations (GNU vs. BSD).

chx’s picture

We know the syntax in the active directory cos it is not hand edited but dumped by the storage driver. So we can and we will query extremely strictly on fixed strings. We will use fgrep. fgrep is available insanely widely.

chx’s picture

Also, if someone else wants to do a research on OpenSolarisIndiana/NetBSD/FreeBSD/OpenBSD/GNU/hellknowswhatsavailableonwindows grep regexp support and add that, please do. I am mostly interested in adding support for fixed strings like tag not 'contains'. I can see the value in the latter but it's simply beyond what I have time for.

chx’s picture

Hrm, discussing more it came to me we could do a test run like grep '^ 40*' config_get_config_directory() . '/system.site.yml' and if we get back 403/404 then we are golden.

amateescu’s picture

We can use find findstr (newer doc page) on windows.

chx’s picture

Status: Active » Needs review
FileSize
5.46 KB

It's nowhere near ready but opinions are welcome. You can test with drush php-eval 'print_r(entity_query("view")->condition("name", "archive")->execute());'

chx’s picture

Ps. yes. the value needs an escapeshellarg. I know. I will add one to the field as well.

dawehner’s picture

FileSize
4.68 KB

Just post the tests.

chx’s picture

FileSize
10.57 KB

Thanks for the test but note that the result is an array of entity id => entity id :) so most of those tests pass except the OR because I havent coded that and the count query because I havent coded that either :D

chx’s picture

Oh and use case for gazillions of configentities: one View per user. Yes you could do customization by saving only the values your customization UI allows but why not simply save the view itself?

Status: Needs review » Needs work

The last submitted patch, 1846454_9.patch, failed testing.

amateescu’s picture

Status: Needs work » Needs review

That's an unrelated test failure, HEAD is broken atm: #1842726: Transliteration component must not contain drupal_alter().

chx’s picture

#9: 1846454_9.patch queued for re-testing.

moshe weitzman’s picture

Seems like a very valuable feature, IMO. Would be OK if it worked only in limited use cases.

dawehner’s picture

FileSize
11 KB
3.66 KB

Documents some parts, but no success to provide a way to list all configuration enties. git grep -L has a really odd behavior regarding the first item of the result.

pounard’s picture

Sounds audacious especially regarding Windows environment support, and potential highly restrictive shared hostings. Does anyone tested this with a proper WinNT install, Apache and IIS?

EDIT: Dawn I missed this https://drupal.org/node/1846454#comment-6758148 comment, anyway this doesn't seem to be implemented yet.

Status: Needs review » Needs work

The last submitted patch, drupal-1846454-15.patch, failed testing.

dawehner’s picture

FileSize
13.3 KB

Some work to get IN() support working.

sun’s picture

Wouldn't it make sense to start with the least performant (and most awkward) implementation first? (i.e., listing and loading all files with a certain config entity prefix and checking certain properties against given values)

Anything OS/platform/tool/access/security-specific on top of that would be an optimization that may or may not be possible — but in any case, it wouldn't be reliable or guaranteed to exist and work.

In other words, an EFQ implementation for config entities won't buy us much if we cannot use it. :)

Thus, can we approach it in this order?

1) Slow, awkward, ugly, but guaranteed to work.
2) Use it.
3) Optimize it.

pounard’s picture

Sun's plan sounds good, first a platform independent implementation, then we can write platform specific implementations and enable them at install time after a environment check.

dawehner’s picture

One advantage of this battle plan would be also, that you would first start with a full test coverage, as there is first full support and then replacing certain bits will ensure that it's still working.

Anonymous’s picture

hmmm. config is small, by number of files (in the thousands) and size.

why not shove them into a simple mysql table and use LIKE '%all the search terms%' ?

and it would be pluggable, so more sophisticated sites can use something better.

chx’s picture

because it's absolutely impossible to react to config storage writes.

chx’s picture

Status: Needs work » Needs review
FileSize
6.5 KB

This is a new beginning based on the fantastic work beejeebus done: first came up with the idea of a denormalization table in #22 then in #1887244: use Config->save() and Config->delete() on import made it possible. This is not working yet -- the query engine is not written, the denormalization is.

chx’s picture

Title: ConfigEntities could query with grep » Add Entity query to Config entities
FileSize
26.15 KB

It's slowly coming together.

chx’s picture

FileSize
11.87 KB

That's the wrong patch.

Status: Needs review » Needs work

The last submitted patch, 1846454_25.patch, failed testing.

dawehner’s picture

FileSize
18.94 KB

Just some small changes here and there, continue to work on.

plach’s picture

Isn't this reintroducing something (potentially) like the active store we had prior to move to config cache? If I'm not mistaken we are writing more or less the same data in {config_entity_denormalized} and in {cache_config}, letting serialization alone.

Not sure where I'm going with this post, I was just a bit suprised to see this solution. I may be totally missing something.

dawehner’s picture

Well config_entity_denormalized is all about enable to query against config, but cache_config
is all about caching for loading, so they fullfill two orthogonal use-cases and also the data-structure itself is simply not compatible.

We should certainl clear document that this table is NOT the actual storage.

plach’s picture

also the data-structure itself is simply not compatible.

What I did not consider previously is that, if I understand correctly, the denormalization table holds one row per value, while cache_config holds one row per config object, correct?

dawehner’s picture

@plach

Exactly that is the difference, they are fundamental different.

I'm wondering whether we want to require this table to be part of system module, but yeah there is probably no better place to do it.

chx’s picture

Status: Needs work » Closed (won't fix)
xjm’s picture

Status: Closed (won't fix) » Needs work

Unilaterally wontfixing an issue is rude to other people following the discussion. One point of criticism in IRC is not reason to do so, either.

chx’s picture

So here's what happened. It does not seem the best to put this into system because if you never run a config query why bother with populating this table. So perhaps a separate module would be better. However, such a module would eventually become a dependency of views_ui and because it's so technical I thought perhaps standard should hide it.

This is what transpired on IRC:

[Saturday, January 19, 2013] [12:41:17] <chx> webchick: what do you think of creating a core/modules/config_entity_query, enabling it from standard and making standard also hide it from the modules interface? cos you have no reason to disable it. but minimal might.
[Saturday, January 19, 2013] [12:41:41] <webchick> chx: I don't like the idea of removing modules form the UI for any reason. It harms learnability
... then I described how we plan to use this to create a View for all Views.
[Saturday, January 19, 2013] [12:54:50] <msonnabaum> what scares me, is this is the result of using config entities for everything
[Saturday, January 19, 2013] [12:55:00] <msonnabaum> if something needs queryability, why is it a config entity?

I have, very carefully removed myself from all these issues. I am not making any architecture decisions, deliberately so, I avoid any issue like that like the plague. I do not even want to know whether something or anything should be a config entity. I am worried to no end how Drupal 8 is going to end up with all this new things, with everything being something different and I do not want to discuss this in every single issue so I rather do not say a word anywhere and confine myself to 'executable' issues and let others decide arch. This actually helps Drupal greatly because we save a helluva lot of debates -- this comes at a great personal cost where I just shut up where I was not used to this. And my restraint is rewarded by trying to pull me into another one of those debates.

I still do not know how to continue because after msonnabaum derailed the discussion into another meta one I lost it and now noone talks to me.

tim.plunkett’s picture

FileSize
36.4 KB

In D7 Views, we had the ability to filter and sort and search Views.
d7-views-list.png

In addition, there is EntityStorageControllerInterface::loadByProperties(). ConfigStorageController doesn't actually use that, but BlockStorageController does, but loading ALL the blocks, and foreaching over them. We should be moving that up to the parent anyway, since blocks aren't special, but that is horribly performant.

This would allow us to actually find and then load only the config entities we actually need. We talked about this as a "nice to have" in Paris, but discussed it seriously at the pre-BADCamp sprint.

In #19, sun suggested putting the grep idea on hold and going with a working implementation. That's in BlockStorageController in HEAD right now. This would be the next step.

tim.plunkett’s picture

I think config.module would be a reasonable place to put this.
Views UI already has some of its D7 functionality moved in there (sync, overridden) anyway.

swentel’s picture

This would be a life saver for the Field API CMI conversion, unless we come up with some sort of insane mechanism there that would be a mess to write and maintain, so if this is available just in the system (so without a module or whatever), + 1000. Ping me in case you feel this is workable so I can test this with that conversion.

chx’s picture

So the decision is to move it to config so that the patch can be tested on the bot and then either sun's installer patch or PHP 5.3.10 happens (both of which makes the patch pass as it is) then we can discuss on moving it back to system for field's sake. It doesn't make a lot of sense to make it a separate module if the required field module depends on it.

swentel’s picture

There 's an entity module which was re-introduced for the entity displays, so maybe that's a better place ? It's required anyway and then we don't need to wait for either php 5.3.10 or the other patch.

chx’s picture

That indeed sounds the best place!

xjm’s picture

chx’s picture

Status: Needs work » Needs review
FileSize
22.96 KB

Let's take a look at this.

Status: Needs review » Needs work

The last submitted patch, 1846454_43.patch, failed testing.

dawehner’s picture

Status: Needs work » Needs review
FileSize
2.56 KB
23.66 KB

Just added another test with nested conditions groups, though it fails at the moment.

At some point $conditionContainer is an instance of Condition not sql, can you please ensure that this fix is correct?

dawehner’s picture

FileSize
4.52 KB
24.45 KB
+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Denormalize.phpundefined
@@ -0,0 +1,117 @@
+  public function configSave(ConfigEvent $event) {
+    $transaction = $this->connection->startTransaction();
+    $this->configDelete($event);
+    if ($this->entityType && $this->connection->schema()->tableExists('config_entity_denormalized')) {
+      $this->insert = $this->connection->insert('config_entity_denormalized')
+        ->fields(array('entity_type', 'entity_id', 'name', 'value'));
+      $this->values($this->config->get());
+      $this->insert->execute();
+    }

It feels wrong that you can only get the entity type once something already called a configDelete() operator. Is that intended?

Fixed some minor documentation/codestyle things.

This interdiff is relative to #45

Status: Needs review » Needs work

The last submitted patch, drupal-1846454-46.patch, failed testing.

chx’s picture

Status: Needs review » Needs work

The last submitted patch, 1846454_48.patch, failed testing.

chx’s picture

Status: Needs work » Needs review
FileSize
69.29 KB

Back to square one: by the decree of catch, we do not denormalize. So here's a complete in memory implementation, tested a "bit". Huge props to dawehner who wrote the sorting code and quite a few tests.

chx’s picture

FileSize
24.48 KB

Opsie, forgot to merge origin.

tim.plunkett’s picture

As I read through I was looking for real stuff to discuss, but all I found were nitpicks. Amazing work, and insanely awesome test coverage!

-----

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Condition.phpundefined
@@ -0,0 +1,126 @@
+  public function compile($holder) {

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Query.phpundefined
@@ -0,0 +1,55 @@
+    $holder = new \stdClass();
+    $holder->sort = $this->sort;

$holder seemed an odd name, and stdClass an odd choice. Apparently the interface calls it $query, and doesn't typehint it, so I guess its okay.

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Condition.phpundefined
@@ -0,0 +1,126 @@
+    foreach ($this->conditions as $condition) {
+      if ($condition['field'] instanceOf ConditionInterface) {
+        $complex_conditions[] = $condition;
+      }
+      else {
+        $simple_conditions[] = $condition;
+      }

Maybe a comment here explaining the difference between simple and complex conditions? One implements an interface, the other...?

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Condition.phpundefined
@@ -0,0 +1,126 @@
+        // Iterate over all conditions and act based on whether they are a condition
+        // group or a single condition.

Rewrap this to 80 chars

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Condition.phpundefined
@@ -0,0 +1,126 @@
+            $match= $condition['operator'] === 'IS NULL';

missing a space after $match

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Query.phpundefined
@@ -0,0 +1,55 @@
+      uasort($entities, function(&$a, &$b) use ($property, $direction) {

Why the & on $a and $b?

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Query.phpundefined
@@ -0,0 +1,55 @@
+        $value_a = isset($a->{$property}) ? $a->{$property} : '';
+        $value_b = isset($b->{$property}) ? $b->{$property} : '';

These are entities, right? Can we do $value_a = $a->get($property); so that protected properties work?

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Query.phpundefined
@@ -0,0 +1,55 @@
+    // Let the pager do it's work.

s/it's/its

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/Query.phpundefined
@@ -0,0 +1,55 @@
+    return drupal_map_assoc(array_keys($entities));
+  }
+}
diff --git a/core/modules/entity/lib/Drupal/entity/ConfigQuery/QueryFactory.php b/core/modules/entity/lib/Drupal/entity/ConfigQuery/QueryFactory.php

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/QueryFactory.phpundefined
@@ -0,0 +1,29 @@
+    return new Query($entity_type, $conjunction);
+  }
+}
diff --git a/core/modules/entity/lib/Drupal/entity/EntityBundle.php b/core/modules/entity/lib/Drupal/entity/EntityBundle.php

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+    $this->assertEqual(sort($result), $expected);
+  }

Missing blank line before end of the class

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/QueryFactory.phpundefined
@@ -0,0 +1,29 @@
+ * Factory class creating entity query objects for the config backend.

Should start with a verb, maybe "Provides" or "Defines"

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/QueryFactory.phpundefined
@@ -0,0 +1,29 @@
+   * Instantiate a entity query for a certain entity type.

Instantiates an entity query...

+++ b/core/modules/entity/lib/Drupal/entity/ConfigQuery/QueryFactory.phpundefined
@@ -0,0 +1,29 @@
+   *   A entity query for a specific configuration entity type.

An entity query

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+  static $modules = array('config_test');

public static, and needs a docblock

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+   * Stores all config entities created for that test.

the test, not that test

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+  protected $entities;
...
+    $this->entities = array();

Could move the = array() up to the property

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+    $this->kernelEnvironment = 'config_entity_query';

This doesn't have a declaration above

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+    $entity = entity_create('config_query_test', array(
+        'label' => $this->randomName(),
+        'id' => 1,
+        'number' => 31,
+      )

The indentation throughout is weird, most entity_create() calls just have )); on the last line and the values indented 2 spaces.

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+    $entity->save();
+  }
+
+
+  /**
+   * Test basic functionality.

Extra line

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+    $this->assertEqual($count, count($this->entities));

It probably doesn't matter, but you could s/assertEqual/assertIdentical throughout just to be 100% sure

+++ b/core/modules/entity/lib/Drupal/entity/Tests/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,433 @@
+   * @param $expected

@param array $expected

chx’s picture

FileSize
26.53 KB

Because of the double upload up there this might have slipped: huge props to dawehner for writing most of the tests and the base of the sort code.

Quite some cleanup: the superfactory is now ContainerAware and gets an EntityManager passed in which is then handed down to the backend specific factories via get. The field SQL backend will be able to get rid of entity_get_info once #1892462: EntityManager should use the CacheDecorator is in.

I moved the classes back to Core because as we do not SQL any more, we do not need a module space. The test moved to system.

Then I addressed almost all except "could move the = array() up to the property" -- that doesn't work because the class is not reinstantiated between test method runs and all the entities would accumulate in $entities.

assertIdentical was a great idea because it turned out the tests were broken (by me, Daniel doesn't make stupid mistakes like this), I was comparing the return value of sort (which is always TRUE) to the expected value and as we know TRUE == whatever almost always tends to be TRUE... There were, however, enough safeguards in place (in the form of counts) that the tests were *still* valueable. This now has been fixed and assertResults has been made significantly more resilient, the number of asserts climbed from 50 to 88 and now assertResults, true to its to own doxygen does not expect $expected to be sorted ahead of the time. At the same time, 30 LoC was deleted.

Adding an interdiff is entirely pointless so I skipped that.

chx’s picture

FileSize
653 bytes
26.53 KB

Implemented "These are entities, right? Can we do $value_a = $a->get($property); so that protected properties work" for Condition as well.

chx’s picture

FileSize
735 bytes
26.51 KB

Except the if beforehands needs to be converted too.

Status: Needs review » Needs work

The last submitted patch, 1846454_55.patch, failed testing.

dawehner’s picture

So one general problem I don't know how to address, is that you can't use $config->get('display.default.display_options.path') yet as it is not a simple property.

catch’s picture

Just to clarify on denormalization in case this comes back to bite me in a year:

I don't think it's worth denormalizing in the first implementation, that's something we can add later and even potentially backport from Drupal 9.

That only holds if usage of this API is restricted to cache misses and administrative listings. If code is running this in the critical path then it's doing something very wrong.

There might be valid use cases (mass updates?) where configuration objects of a particular type need to be loaded all at once and edited. If we're concerned about memory in this case we could use an iterator rather than loading everything at once into an array.

chx’s picture

Status: Needs work » Needs review
FileSize
30.85 KB

We have switched to using config arrays to address #57. As a bonus, we not just match display.default.display_options.path but display.*.display_options.path as well. I felt that'd be handy. The interdiff is, again, rather meaningless. We are reaching 100 asserts in this patch alone.

chx’s picture

FileSize
12.75 KB
31.32 KB

This is mostly just tweaks , little better doxygen, test fixes and the like. I removed the single ->condition('foo') handling as that is most definitely premature optimization, it's now handled the same as ->condition('foo.bar'). Accidentally #59 didn't handle foo.bar although it did handle foo.*.bar this is now both fixed and tested. We now have 98 passes from 40 queries. I attached an interdiff -- note that match() didn't change at all, just moved.

dawehner’s picture

FileSize
2.26 KB
31.5 KB

Some small cleanups.

tim.plunkett’s picture

This is RTBC but for a few missing docs and coding standards.
----

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Condition.phpundefined
@@ -0,0 +1,171 @@
+   * Match for an array representing one or more config paths.

Matches

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Condition.phpundefined
@@ -0,0 +1,171 @@
+   * @param $condition
+   *   The condition array as created by the condition() method.
...
+   * @param $condition
+   *   The condition array as created by the condition() method.
+   * @param $value
+   *   The value to match against.

Missing type hinting

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Condition.phpundefined
@@ -0,0 +1,171 @@
+  protected function matchArray($condition, array $data, array $needs_matching, array $parents = array()) {
...
+  protected function match($condition, $value) {

If condition is always an array, can type hint here

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Condition.phpundefined
@@ -0,0 +1,171 @@
+   * Do the actual matching.

Maybe "Performs the actual matching."? Needs a verb

+++ b/core/lib/Drupal/Core/Config/Entity/Query/Condition.phpundefined
@@ -0,0 +1,171 @@
+   * @return bool
+   *   TRUE when matches.

Blank line before @return

+++ b/core/lib/Drupal/Core/Config/Entity/Query/QueryFactory.phpundefined
@@ -0,0 +1,53 @@
+   * Instantiate a entity query for a certain entity type.

Instantiates

+++ b/core/lib/Drupal/Core/Entity/Query/QueryFactory.phpundefined
@@ -7,24 +7,24 @@
   /**
-   * var \Symfony\Component\DependencyInjection\ContainerInterface
+   * @var \Drupal\Core\Entity\EntityManager
    */
-  protected $container;

This has the @var, but no comment above it

+++ b/core/lib/Drupal/Core/Entity/Query/QueryFactory.phpundefined
@@ -7,24 +7,24 @@
+   * @param \Drupal\Core\Entity\EntityManager $entity_manager
    */
-  function __construct(ContainerInterface $container) {
-    $this->container = $container;
+  public function __construct(EntityManager $entity_manager) {

This has the @param, but no comment below it, nor a docblock for the actual method (Overrides \Symfony\...)

+++ b/core/modules/config/tests/config_test/lib/Drupal/config_test/Plugin/Core/Entity/ConfigQueryTest.phpundefined
@@ -0,0 +1,47 @@
+ *  @see \Drupal\entity\Tests\ConfigEntityQueryTest

Indented too far

+++ b/core/modules/config/tests/config_test/lib/Drupal/config_test/Plugin/Core/Entity/ConfigQueryTest.phpundefined
@@ -0,0 +1,47 @@
+   * A number used by the sort tests.
+   */
+  public $number;
...
+   * An array used by the wildcard tests.
+   */
+  public $array;

Missing @var

+++ b/core/modules/config/tests/config_test/lib/Drupal/config_test/Plugin/Core/Entity/ConfigQueryTest.phpundefined
@@ -0,0 +1,47 @@
+  public $array;
+}
diff --git a/core/modules/field_sql_storage/lib/Drupal/field_sql_storage/Entity/Query.php b/core/modules/field_sql_storage/lib/Drupal/field_sql_storage/Entity/Query.php

Missing blank line before end of class.

+++ b/core/modules/system/lib/Drupal/system/Tests/Entity/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,443 @@
+    parent::setUp();
+   $this->entities = array();

Indentation is wrong, and we usually leave a blank line after parent::setUp()

+++ b/core/modules/system/lib/Drupal/system/Tests/Entity/ConfigEntityQueryTest.phpundefined
@@ -0,0 +1,443 @@
+   * Test basic functionality.
...
+   * Test count query.
...
+   * Test dotted path matching.

Should start with "Tests"

dawehner’s picture

FileSize
6.49 KB
32.58 KB

Indeed the original entity query patch didn't went through a proper doc review.

tim.plunkett’s picture

Status: Needs review » Reviewed & tested by the community

Thanks @dawehner!

This is fantastic work.

amateescu’s picture

FileSize
661 bytes
33.22 KB

While we're fixing doc issues from the initial entity query patch, this missing @return has bugged me a lot in the menu links conversion :)

dawehner’s picture

Issue tags: -Configuration system

Well seems a bit out of scope but I don't think this would block a release.

sun’s picture

This looks fantastic.

Exactly the right baseline on which we may be able to advance on with faster/better/optimized implementations, but this one is guaranteed to always work.

Awesome work, everyone!

catch’s picture

Title: Add Entity query to Config entities » Change notice: Add Entity query to Config entities
Priority: Normal » Critical
Status: Reviewed & tested by the community » Active
Issue tags: +Needs change record

I've opened #1900962: Use Config Entity query for views_get_applicable_views(), that's a definite use case for this that can happen now.

Went ahead and committed/pushed this to 8.x to unblock other work. I'm a bit concerned about this getting abused everywhere (i..e more or less anywhere in the critical path), but we'll see.

tim.plunkett’s picture

dawehner’s picture

chx’s picture

Title: Change notice: Add Entity query to Config entities » Add Entity query to Config entities
Status: Active » Fixed
Issue tags: -Needs change record

The change notice is good, the random failure is patched.

plach’s picture

The new example in the change notice does not seem to be valid PHP, maybe a wrong copy/paste?

olli’s picture

Syntax was fixed already. It was also listing disabled views.

chx’s picture

Priority: Critical » Normal

Automatically closed -- issue fixed for 2 weeks with no activity.