- 🇬🇧United Kingdom catch
This is still a task, or even a feature request, lack of features isn't a bug. We also didn't have generic revision routes/UI until a couple of months ago years after they were theoretically possible, but those were added as features/tasks too.
It's much easier to have dynamic database tables than it was when this issue was opened, so I would suggest something like this:
1. Convert the taxonomy_index maintenance code to a service.
2. Make that service entity-generic and use per-entity-type tables (using a similar pattern to the database cache backend), that will help keep the number of rows per table somewhat under control and save having to store entity_type and querying on it.
The other option would be to port https://www.drupal.org/project/mv → to Drupal 10 then propose it as an experimental module in core, and then we could drop the taxonomy_index-specific code altogether.
- 🇺🇸United States saltednut Chicago
Not seeing documentation around MV or much usage? Option 2 sounds really doable and doesn't require an experimental module. Converting things over to services has been a goal since we moved to this architecture so I'd lean toward supporting that.