From #2391829: ContentUninstallValidator relies on the not required ContentEntityStorage::hasData() method :

[Berdir] KeyValueEntityStorage just a test implementation really, I hope nobody is going to use it for real data :)

[yched] OK, but nothing really hints that it's a test-only-do-not-use-for-real implementation :-). It's not in a "test" directory or namespace, Drupal\Core\Entity\KeyValueStore makes it kind of "officially endorsed", and no comment or phpdoc say anything about that either
So maybe we should open a separate issue to move that class to a test folder somewhere ?

[Berdir] /me points to @timplunkett ;) I know and I'd be happy to do that.

So if @timplunkett approves, let's do that ?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

Issue summary: View changes
Dave Reid’s picture

I was planning on using it for actual data and had use cases. I would be sad to have this relegated to test code only.

yched’s picture

@Dave Reid : Fair enough. Any thoughts on #2391829: ContentUninstallValidator relies on the not required ContentEntityStorage::hasData() method then ? :-)

If we want to have EntityStorageInterface::hasData(), an implementation for KeyValueEntityStorage would currently need to use $this->keyValueStore->getAll(), which would be a perf killer...

Berdir’s picture

Assigned: Unassigned » tim.plunkett

Yes, this doesn't scale at all, not just hasData() but entity query is basically the same implementation as config entities AFAIK; which means, load them all and then search in PHP.

Let's ask @timplunkett.

Berdir’s picture

Title: Move KeyValueEntityStorage to a test foilder » Move KeyValueEntityStorage to a test folder
tim.plunkett’s picture

Status: Active » Needs review
Issue tags: +Needs issue summary update
FileSize
3.33 KB

"It's in my way, let's [re]move it" is exactly why I wanted this added.

As @Berdir points out, ConfigEntityStorage is no worse than KeyValueEntityStorage in terms of entity query.

Why not just improve KeyValueStoreInterface? hasData() should be cheap for this.

Also, way to lure me back to d.o from vacation by assigning an issue to me :) Happy New Years!

Berdir’s picture

Also, way to lure me back to d.o from vacation by assigning an issue to me :) Happy New Years!

Sorry and to you to! :)

This solves the hasData() problem, but it does not solve the entity query implementation. The difference to config entities in my opinion is that they have scalability issues in many different ways, like the list UI's not having any pagers, we also commonly load them all for various operations.

That is not obvious for a key value storage, you might expect this to scale. But I think we had this discussion before ;)

tim.plunkett’s picture

Assigned: tim.plunkett » Unassigned
Status: Needs review » Needs work

I still don't see how this is worse than config storage right now.
Other than repurposing this issue for the above example patch, I think this issue should be won't fixed.

Gábor Hojtsy’s picture

KeyValueEntityStorage is also used for config entities. As found in #2136559: Config entity admin lists show configuration with overrides (eg. localized), if you attempt to actually use it for config entities, it does not support overrides, such as settings.php, language, etc. which is a huge part of the config system. ConfigEntityStorage works with the config factory to load things through which is where the overrides are implemented. KeyValueEntityStorage is also used in tests direct with the config system and does not implement the config entity storage interface, so if some methods are actually invoked on it, it will fail hard. The tests do not cover those cases which is why it does not fail now. We are about to introduce a config specific subclass at #2136559: Config entity admin lists show configuration with overrides (eg. localized) which would not actually resolve those problems due to the scope of that issue. If this storage is to be considered a real thing not a test, it would need to step up in a big way. It manages to pass some limited tests now which is why many of us look at it as a test implementation not useful for a real scenario.

Gábor Hojtsy’s picture

Status: Needs work » Needs review
alexpott’s picture

And it does not support config entity dependency management see #2416409-47: Delete dependent config entities that don't implement onDependencyRemoval() when a config entity is deleted

I propose that we remove the ability to use storage classes that don;t extend ConfigEntityStorage. If you want to store configuration in something other than the db then you need to swap out all configuration storage.

alexpott’s picture

FileSize
7.23 KB

Here is a patch that removes the config entity part of this.

Gábor Hojtsy’s picture

Makes total sense to me.

Status: Needs review » Needs work

The last submitted patch, 12: 2393751.12.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
2.76 KB
9.99 KB

Fix the test by removing it - it's pointless need we are not swapping out the config entity storage. Added tests for the exception.

tim.plunkett’s picture

This needs a new issue title and issue summary, but this effectively does what #1853856-25: Document that ConfigEntityBase and ConfigStorageController are tightly coupled intended over 2 years ago.

tim.plunkett’s picture

Title: Move KeyValueEntityStorage to a test folder » Enforce tight coupling between ConfigEntity and ConfigEntityStorage
Component: entity system » configuration entity system
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs issue summary update
Related issues: +#1853856: Document that ConfigEntityBase and ConfigStorageController are tightly coupled
alexpott’s picture

Category: Task » Bug report

This is now fixing a bug. Thanks @tim.plunkett for updating the the issue title and summary.

Berdir’s picture

Hm, but this doesn't address the original reason this issue was opened, removing the config part only addresses part of the problem.

alexpott’s picture

@Berdir oops you're right - I seem to have inadvertently diverted this issue - sorry. Is the hasData() the only problem with using key value storage for content entities? Shall we merge the patches - or open a new issue?

Berdir’s picture

I think we still weren't able to convince tim about the test module part, so merging isn't a good idea. Maybe we should just re-open #1853856: Document that ConfigEntityBase and ConfigStorageController are tightly coupled (which was closed as won't fix, which is wrong now anyway) and post the patch there?

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Okay moved my patch to #1853856: Document that ConfigEntityBase and ConfigStorageController are tightly coupled and re-opened. Going to revert the issue summary on this issue.

alexpott’s picture

Title: Enforce tight coupling between ConfigEntity and ConfigEntityStorage » Move KeyValueEntityStorage to a test folder
Component: configuration entity system » entity system
Category: Bug report » Task
Issue summary: View changes
Status: Needs work » Needs review
Issue tags: +Needs issue summary update
Related issues: -#1853856: Document that ConfigEntityBase and ConfigStorageController are tightly coupled
alexpott’s picture

Berdir’s picture

Thanks!

cilefen’s picture

Is this still needed? It seem so.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

amateescu’s picture

Title: Move KeyValueEntityStorage to a test folder » Document that KeyValueEntityStorage is not scalable beyond a few hundred entities
Version: 8.4.x-dev » 8.5.x-dev
Status: Needs review » Needs work

So #1853856: Document that ConfigEntityBase and ConfigStorageController are tightly coupled removed the ability of using KeyValueEntityStorage for config entities, and if we want to keep this storage as a non-test implementation, we should simply document that it's not designed to be scalable like the SQL content entity storage.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.