Contrib.social

Pursue alternative parsing logic

Open on Drupal.org →
Created on 7 April 2023, almost 2 years ago

Problem/Motivation

The solution to our performance / memory usage issue was a creative memoization solution that ensures we always process an item once. It's a really great solution to prevent the infinite loops that were killing us.

But it got me thinking, What if we break the logic out of hooks?

https://api.drupal.org/api/drupal/core%21modules%21views%21views.api.php... suggests that an alternative to using hook_view_data is to: 

create a class implementing \Drupal\views\EntityViewsDataInterface and reference this in the "handlers.views_data" annotation in the entity class. The return value of the getViewsData() method on the interface is the same as this hook, and base class in \Drupal\views\EntityViewsData will take care of adding the basic Views tables and fields for your entity. See the Entity API topic for more information about entities.

So is that possible? Is it possible to programmatically create an object that implements EntityViewsDataInterface per ConfigEntityType. If that's possible then we could also make the object have a getViewsData() method. That method would likely be be the bit that we create as a sensible default, but also have the ability to be overridden by others in case it doesn't fit their needs.

This might be such a large change that a version 3 of this module might be warranted.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

2.0

Component

Code

Created by

🇺🇸United States cosmicdreams Minneapolis/St. Paul

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @cosmicdreams
  • Comment almost 2 years ago →
    🇺🇸United States cosmicdreams Minneapolis/St. Paul

    Each entity type that we are parsing is a ConfigEntityType. We are specifically checking if they are one, and if not we "continue" out of process to skip to one that is (until done). As a result, we can benefit from the Entity API methods of a ConfigEntityType.

    There are a couple of methods that are extremely interesting from there:

    • ConfigEntityType->getKeys() : gets the properties that are used to index data.
    • ConfigEntityType->getLookupKeys : "gets keys that are used for fast lookup"
    • ConfigEntityType->getPropertiesToExport() : Gets all the data that would be exported to a yml file.

    Also it appears that we may be overwriting existing work to establish views for Blocks and Tours. When I check to see if any configuration entity types already have a view builder, those two come up. We should avoid parsing configuration entities that have already put in work to establish their own views, so that we don't duplicate or override what they've done.

    Working with the entityTypeManager to get a list of config entity types has given me a path to complete ✨ Consider adding allowed config list Needs work I think I'll shelve this effort for now and complete that one. It has the greatest potential to improve our install-time resource demands / performance.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024