Currently it is not possible to show fields from the backend that were inserted outside of the scope of Drupal. When working with backends such as elastic search and solr there are use cases where there are fields available in the documents that are not part of the Drupal indexing logic. Or in the case of integrations with existing Solr/Elastic Search indexes we want to show lists of that data without touching that data. It could also be that you want to create facets for those fields.
In the case of multisite searching, we want to show data from another drupal site in our Drupal 8 site, adding this would allow that.
Add a section in the search api field listing page that shows the "external" fields,filled up with information straight from the backend. If they are available in the field listing, facet api and views can easily use those as well to add support for them. They should not be removable and do not have any action associated with them. They should be collapsed by default as this is a rather advanced use case.
Everything
drunken_monkey is refactoring the search api field listing and how fields are being added. This impacts that work or vice versa. It's recommended to wait with this issue until that refactoring is done.
Some new functions to get external fields should be added to the backend interfaces
Not that I know
This issue was identified as a Beta Blocker for Drupal 8. We sat down and figured out the value proposition and amount of work (story points) for this issue.
Value and Story points are in the scale of fibonacci. Our minimum is 1, our maximum is 21. The higher, the more value or work a certain issue has.
Value : 13
Story Points: 13
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 2625154-8--backend_defined_fields.patch | 12.23 KB | drunken monkey |
Comments
Comment #2
drunken monkeyHm, yes, probably makes sense. While it's easy to implement something like this in the module itself (via a datasource and some custom code), I guess it would save a lot of code and also potentially make things clearer for users if we implement this right in the Search API itself.
As you said, this is postponed for the moment, but then we should definitely look at it again.
Btw, the issue for refactoring the "Fields" tab/workflow is #2574969: Add a Views-like UI for adding fields.
Comment #3
mkalkbrennerThis is a real use-case, especially for the multisite feature that came from apachesolr 7.x.
See #2682347: Expose solr-only fields to views.
Comment #4
drunken monkeyComment #5
drunken monkeyThis is a first attempt at implementing this, but most likely needs some refining. Best would be if someone from the Solr module could take a look and maybe try to implement the method, and then we'll see whether this makes sense or where it has weaknesses.
Some things to (additionally) consider:
Index::getFields(TRUE)?Comment #8
drunken monkeyThis should fix the test fail, but the questions in #5 of course still remain.
Comment #10
drunken monkeyMost likely just the branch fails.
Comment #11
borisson_Looks great, good work @drunken monkey
Comment #12
mkalkbrennerHaving that support implemented within Search API will be great!
Even if I still have to figure out how the building blocks to implement multi-site search using this new API, I think the current proposed starting point should be committed quickly.
Comment #14
drunken monkeyOK, if you say so. Thanks for reviewing!
Committed.