Search API/ SOLR integration

Would love this as well for D8/9 version!

See also #3016821: Sort by Entityqueue

This issue fork could really use some initial review from people knowledgeable about Entityqueue and Search API.

It works for my purpose but definitely needs work (in particular needs to deal appropriately with the eventuality that the same entity gets added to more than one entityqueue).

This does not trigger an update to the index when an item is added, removed, or re-ordered in an update queue.

Possible code i'm hoping for Search API advice on in https://www.drupal.org/project/search_api/issues/3016821#comment-16054098

It seems that when removing an entity from the queue, the index is not updated. In the hook_update only the entities of the current list are included in the entity update of search_api.entity_datasource.tracking_manager.

If I also include the entities that are removed, the overview updated correctly. I don't know if this is the best way.

Here is patch

Here is the updated patch. It removes the item if it has been removed from the Entity Queue.

This patch applying fine

The issue I am having, and don't understand how to solve, is that while one item can be in multiple subqueues, that item's entity_queue weight delta value only gets stored in the index for one of those subqueues (and does not specify which one). mlncn mentioned this above in comment #4. Is it possible to fix this?

Here are some queries to demonstrate what I am looking at:

MariaDB [db]> select * from entity_subqueue__items where items_target_id = 6307;
+---------------------+---------+---------------------------+-------------+----------+-------+-----------------+
| bundle              | deleted | entity_id                 | revision_id | langcode | delta | items_target_id |
+---------------------+---------+---------------------------+-------------+----------+-------+-----------------+
| exhibition_artworks |       0 | exhibition_artworks__6299 |         376 | en       |     8 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__6886 |         403 | en       |   120 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__6918 |         404 | en       |    21 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__7129 |         414 | en       |    52 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__8588 |         467 | en       |    57 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__9040 |         490 | en       |    37 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__9614 |         511 | en       |    17 | 6307            |
| exhibition_artworks |       0 | exhibition_artworks__9678 |         515 | en       |    10 | 6307            |
+---------------------+---------+---------------------------+-------------+----------+-------+-----------------+
8 rows in set (0.005 sec)

MariaDB [db]> select * from search_api_db_general_entityqueue_weight where item_id like '%6307%';
+----------------------+-------+
| item_id              | value |
+----------------------+-------+
| entity:node/6307:und |     8 |
+----------------------+-------+
1 row in set (0.002 sec)

The 8 value in the latter table corresponds to the delta in the first row of the former.

For items only in a single subqueue, this patch is working fine.

I think this search api issue is addressing how to do this: https://www.drupal.org/project/search_api/issues/3034182

So if I understand correctly, we need a custom datasource plugin, and we need our search api item_id to include the subqueue entity id. So in my example, instead of entity:node/6307:und, the item id should (maybe?) look like entity:subqueue/exhibition_artworks__6299:6307:und. Maybe subqueue_item would be more appropriate. I wonder if we would be able to accomplish this by extending the content entity datasource plugin (defined in search api).

In this example, I have assumed a custom datasource plugin entity:subqueue, and added the subqueue id to the item_id exhibition_artworks__6299. Of course the datasource plugin id could be changed, and the subqueue id does not necessarily have to come first, but I think it makes sense.

It may be worth experimenting with https://www.drupal.org/project/search_api_revisions and using the code there for reference, while trying to understand how to implement and use a custom datasource that can index the same node multiple times. FWIW this one does extend the content entity datasource as I mentioned above.

I guess the issue with extending the content entity datasource is that entity queue is able to handle configuration entities as well. Any thoughts on the implications here? For simplicity, it might still make sense to start out by extending the content entity datasource. I don't think config and content items can both exist in the same queue anyway.

I don't think config and content items can both exist in the same queue anyway.

That's correct :) And I think the approach with extending the content entity datasource is great, a followup issue can be opened if someone needs Search API support/integration for config entities.

No new work yet, just rebasing ^

Here is the new patch (same thing, just matching the issue fork)