Opened 8 years ago

Last modified 5 months ago

#720 new defect

range vs filter prefixes

Reported by: Olly Betts Owned by: Olly Betts
Priority: highest Milestone: 1.5.0
Component: QueryParser Version: 1.3.5
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Operating System: All

Description

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.

Change History (5)

comment:1 by Olly Betts, 5 years ago

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.

comment:2 by Olly Betts, 3 years ago

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.

comment:3 by Olly Betts, 13 months ago

Milestone: 1.4.x2.0.0

comment:4 by Olly Betts, 13 months ago

Milestone: 2.0.01.5.0

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.

comment:5 by Olly Betts, 5 months ago

Priority: normalhighest
Note: See TracTickets for help on using tickets.