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

demon created this task.Mar 2 2017, 2:47 AM
Restricted Application added projects: Discovery, Discovery-Search. · View Herald TranscriptMar 2 2017, 2:47 AM
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 later on... on the Discovery-Search board.
debt added a subscriber: debt.

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

demon added a comment.Jul 15 2017, 1:34 AM

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 :)