Page MenuHomePhabricator

Implement multiple parameters to prefix: operator on fulltext searches
Open, LowPublic

Description

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.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

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

debt triaged this task as Low priority.Mar 2 2017, 11:04 PM
debt moved this task from needs triage to search-icebox on the Discovery-Search board.
debt subscribed.

We hope to get this looked at in early 2017/2018 fiscal year.

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.

We hope to get this looked at in early 2017/2018 fiscal year.

I hope the end is in sight :)

MPhamWMF subscribed.

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.

RhinosF1 removed a project: Discovery-Search.
RhinosF1 subscribed.

Re-opening tasks and removing from team workboard per IRC feedback given yesterday and discussion with MPham.