It seems to be the case that prefix: operators in lsearchd used to support multiple parameters via pipes (so prefix:foo|bar) which would treat them as an OR operation to look in multiple possible prefixes. I can't think of any sort of reason we can't do something similar. The use case is for search templates that want to look in a couple of places at once.
Description
Event Timeline
Rather than specializing the prefix: operator with special syntax, i'd prefer we get our query parsing into a sane state where we can specify prefix:foo OR prefix:bar
My biggest fear with that approach (while also long overdue and worthwhile) would make it more likely for people to run against query limits. Using | as a separator for values is long-accepted syntax in other places eg: api.php. Cleanup to query parsing should make it pretty easy to break these values on | (nb: skipping it for fields where it doesn't make sense).
This bug, along with a ton of others will really only be fixed by sane query parsing. It's terrible legacy behavior that stems from a need to rapidly prototype, in addition to emulating undocumented behaviors. We didn't start from a formal query language. Eventually someone is going to have to bite the bullet and do it.
I hope the end is in sight :)
Closing out low/est priority tasks over 6 months old with no activity within last 6 months in order to clean out the backlog of tickets we will not be addressing in the near term. Please feel free to reopen if you think a ticket is important, but bare in mind that given current priorities and resourcing, it is unlikely for the Search team to pick up these tasks for the indefinite future. We hope that the requested changes have either been addressed by or made irrelevant by work the team has done or is doing -- e.g. upgrading Elasticsearch to a newer version will solve various ES-related problems -- or will be subsumed by future work in a more generalized way.
Re-opening tasks and removing from team workboard per IRC feedback given yesterday and discussion with MPham.