Allow prefix behavior to depend on the field's type

[rcrowell]

Description

I helped add the exact match query feature last year, but the exact-match prefix = does not seem to work for PathQuery. After stepping through this code for a while tonight, I believe this because MatchQuery does not know to convert its pattern to a memoryview.

The proposed solution here tweaks the way prefixes work, allowing any prefix string to be assigned to a dictionary mapping the field's un-prefixed query type to the prefix's desired query type (use a defaultdict to provide a default query class, if desired).

I thought this made sense (vs simply checking for the field name 'path') to support plugins that may want to use this functionality for their own ends. But is there a better, more straightforward approach that I could have used?

(...)

To Do

• [x] Documentation. (If you've add a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• [x] Changelog. (Add an entry to docs/changelog.rst near the top of the document.)
• [x] Tests. (Encouraged but not strictly required.)

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sampsyo]

While I am sorry I haven't had the bandwidth to do a thorough review on this, the PR already looks very well thought out. I wouldn't object to merging it. My only concern is whether the same high-level fix could be achieved in a simpler way: make MatchQuery aware of bytes. That way, we wouldn't have to switch between different queries based on the type; we could instead just have one type-aware query. (Not clear that this doesn't create other problems.)

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.