range vs filter prefixes

[Olly Betts]

For a range, a prefix like date: needs to be specified with the : (which is because a prefix like $ is allowed).

But for a filter, the : is implicit, and you shouldn't explicitly include it.

This is an inconsistency in the API, and those make the API harder to learn and use.

I think the simplest solution is to optionally allow the : for a filter. Perhaps we should also encourage explicitly specifying it, with an eye to later supporting filters with a prefix which isn't "word and a colon", e.g. #1234 instead of sku:1234, @olly instead of user:olly.

[Olly Betts]

To allow a smooth transition, I suggest we change the code to add : for a filter but only if the prefix ends in an alphanumeric (or maybe a word character, or some rule along these lines). That way date -> date:, date: continues to work, and cases such as @, #, etc can be supported. It doesn't seem useful to try to support parsing something such as: date2019-08-09

This isn't the incompatible change it seems since the way the QueryParser currently parses filter prefixes means that specifying a mapping from date:, @ or # is currently effectively ignored (because the prefix is parsed as a series of word characters followed by a :). So that would be suitable for 1.4.x too, provided the code changes for handling prefixes such as @ and # aren't too invasive. If they are, we could easily just allow date: to mean the same as date at least, and leave cases such as @ and # for git master, or even for the future.

[Olly Betts]

While date2019-08-09 doesn't seem useful, maybe SKU31415 is - for example in an online shop a search for a part code could then be made to reliably return just that item.

It would need to be used with a bit of care to not be confusing though.

[Olly Betts]

Oops, I meant 1.5.0. As noted above this could be backported to 1.4.x if it's not too invasive. We're quite late in the 1.4.x development cycle, but cases like this where we're aiming to improve forward compatibility are worth considering. This needs doing for master first regardless.

[Olly Betts]

maybe SKU31415 is [useful]

I think that's probably not a useful direction to try to go. It gets complex to implement and it's harder for users to understand.

field: prefixes are easy for both implementing and users, and things like @olly and #1234 reasonably so too.

For now I've just added a tweak to allow an optional : on the field parameter from 1.4.26 (043b292aae29ee676f5fa964d3c6a900c4d71307 for master; d38234c44d9abe8aa781738c0a9dfe9fae9db39c for RELEASE/1.4).

Actually implementing filter prefix support for @olly, #1234 is for later.