The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Are you planning on adding this feature for Search API Solr module?
At this moment Search API Solr queries SOLR, retrieves the indexes, and then retrieves the results from MySQL.
We want to store jobs only in SOLR and make the search view query SOLR and display the search results directly from SOLR.
It would be faster and it would eliminate redundancy because the data is already stored in SOLR.
Are you planning on adding this feature?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1154116--retrieve-fields-4.patch | 8.98 KB | drunken monkey |
| #3 | 1154116--retrieve-fields.patch | 9 KB | drunken monkey |
Comments
Comment #1
drunken monkeyNo, I don't plan on adding this feature.
See here for a discussion why not: #1130806: Potential Performance Issues.
Here for performance benchmarks indicating there might not be much of a performance gain: #1135270: Performance comparison with Apachesolr module and Search API module (with benchmarks).
And, lastly, becw is working on a module called "Sarnia", which does pretty much what you want. The Github repository isn't there anymore, though, so you'll have to ask him where (or whether) the code is available, and how far he has gotten yet.
Comment #3
drunken monkeyEven though I still doubt this is a good idea, there were already several requests for this, so I guess we can just add this as an optional setting and let users evaluate and decide themselves.
The attached patch would do this, returning all stored field values of the search results when an option on the server is set.
Note, however, that the field data currently won't be used, until #1089758: Make use of new flexibility for Views field handlers is committed.
Comment #4
drunken monkeyRe-roll.
Comment #5
becw commentedSo, the first round of work on #1089758: Make use of new flexibility for Views field handlers has been committed. At this point, if field values are stored in Solr, then a view built with the Search API Views query backend will not load entities if all of the view's fields are present on the Solr search results. Additionally, values from Solr will be preferred over values from entities.
Given that one of the main points in #1130806: Potential Performance Issues is that "Entities that are loaded will always be up-to-date, invoke Field API magic (including support for translations) as well as other hooks correctly, etc.", perhaps this new behavior is a bug, and Entity values should instead be preferred over values from Solr.
@drunken monkey: perhaps the 'retrieve_data' flag from your patch in #4 should be used to trigger the new Search API Views behavior?
Comment #6
drunken monkeySince no-one complained, protested or objected, I'll just commit this now.
Comment #8
blasvicco commentedI will leave this here for anyone that need to achieve this feature:
Search API Solr PRO