Include entities in taxonomy_index

I have written http://drupal.org/project/taxonomy_entity_index in the meantime. This can only be a 8.x issue since we have to change schema.

Excellent idea - I was just looking for this.

opposed opinion and major bug #1050466: The taxonomy index should be maintained in a node hook, not a field hook

Just a note, #1050466: The taxonomy index should be maintained in a node hook, not a field hook and this issue are not mutually exclusive. The patch there (which is NR, hint, hint) could easily be moved to a generic entity-level hook rather than the specific node hook.

The main concern with adding entities to the index tables is size/performance/overhead, as far as I understand. catch said:

The proper solution for dealing with slow queries due to core's default field storage is either alternative field storage engines (such as mongodb or something like PBS), or something like the materialized view API. Neither of these were anywhere near core inclusion during the Drupal 7 release cycle, and {taxonomy_index} was put in as a compromise between postponing terms as fields on vapourware, vs. joining on all the possible field tables which would've been a significant performance regression. Similar tables exist in both tracker and forum modules to deal with similar problems.

I'm hopeful that the work on materialized view API as part of gsoc, or Damien's proposed document storage model for Drupal 8, would allow us to ship a proper system for this stuff in Drupal 8 rather than these one-off hacks.

So perhaps the D8 issue is really "make something better than index tables."

Since we moved to entities I can see no clear route in core to go from taxonomy to the occurrence of taxonomy on entity instances. Taxonomy data seems to be getting fragmented across fields with no path to find it. One of the great benefits of taxonomy is to allow us to find all things categorised by a particular vocabulary or term.

Is there a place where we can map a vocabulary to the places where its occurrence data is stored?

Or is that something that we need to consider now that we have lost global taxonomy indexing?

Unfortunately, it looks like we missed the boat on this for D8.

...it's a pity though because this is one of the 3 issues required to get the functionality of Taxonomy Entity Index in core so we don't require another extra module for D8. The other two issues are to be fixed in D8 so, can't we make an exception here?

We can make this change in minor version.

Recategorizing as a task, since there is no functional change (the start and endpoints are the same in functionality).

Partly agreed with #8. If we did the bare minimum scope (simply modifying TermStorageSchema::getEntitySchema()) then this is is a straightforward update to add the other entities to the index table. With the new automatic entity schema change handling, it might not even need an update hook (not sure). However, there is also a slight BC break -- queries that are running against this table would suddenly start selecting non-nodes unintentionally. So it's not 100% clear-cut.

The broader "fix it right" scope from #4 is also even feasible to do without BC breaks, and could also probably be developed in contrib before 8.1.x (as Taxonomy Entity Index and mv were in D7).

I do agree that this is not on the table for 8.0.x because it does not meet the criteria in the beta phase criteria.

Keep in mind that there is a workaround as well -- depending on the usecase, one can use EFQ. Or Views. Etc.

There's Materialized views API and its code looks great

Strongly recommend Drupal 8 include this module before its release candidate publication.

Nor does this need to be postponed.

> Recategorizing as a task, since there is no functional change (the start and endpoints are the same in functionality).

Bug, surely?

Views handlers for taxonomy depth aren't available for non-node entities, so a major use case of taxonomy is node-only.

This functionality is not implemented into drupal core yet.
So taxononomy index can work right now only with nodes.

This should really be addressed now.
With media in core we should be able to use a view with a "has taxonomy term...." with media type.

I now use two modules to get results :
- media_taxonomy_filter
- taxonomy_term_depth

Regards,
Hans

Solution for all entities with taxonomy filter, based on module.

entity_taxonomy

It supports all major entities like user, comments, commerce_product, paragraphs and etc...

This module maintain taxonomy_index based on entity_type.

If https://www.drupal.org/project/drupal/issues/2429699 is merged is this ticket still relevant?

@smustgrave: Yes (sadly) it is! ;)
See https://www.drupal.org/project/taxonomy_entity_index

These issues have to be fixed accordingly:
#962664: Taxonomy Index for unpublished entities
#1040786: Include entities in taxonomy_index
#610076: Add a primary key to the {taxonomy_index} table and prevent duplicates being inserted

Currently Drupal Views are still very "Content" (node) centric in this part.

Update tag. This also needs an issue summary update.

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.

Not seeing documentation around MV or much usage? Steps 1 and 2 recommended sound doable and do not 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.