Currently, warnings and ignored search keys can only be set on the search result set object – which makes sense conceptually, but less so regarding the workflow, since warnings and ignored search keys are often/mostly already discovered when building the query. Therefore, being able to set the warnings and ignored search keys at that point, too, would make sense.
I think the simplest solution would be to actually create the results object right away in the query class (instead of leaving that to the server's backend plugin, as I think we do currently) and provide a getter for it. A small change, but making things cleaner and simplifying a few parts of our code (like the "Stopwords" processor, which currently has to remember the ignored keys itself and then run on postprocessSearchResults() just to set them on the result set).
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:
Story Points:
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2641396-5--create_results_in_query.patch | 15.96 KB | drunken monkey |
Comments
Comment #2
drunken monkeyThis implements the suggested solution of creating the results right in the query.
Makes the interface a bit weird by not having a return value for
Backend:search()anymore – but it does clean up several places in the code, so I'd call that an improvement.Comment #5
drunken monkeyMissed one place in the code.
Comment #6
borisson_If the tests are green, I agree with this issue.
Comment #8
drunken monkeyOK, great! Thanks for reviewing!
Committed.
Comment #9
drunken monkey