Ticket #7558 (new enhancement)
Opened 3 years ago
Last modified 16 months ago
New TracQuery match operator for "contains the word" would be useful
| Reported by: | meitarm@… | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | next-major-0.1X |
| Component: | ticket system | Version: | 0.11.1 |
| Severity: | minor | Keywords: | query keywords exact match |
| Cc: | mmitar@… | ||
| Release Notes: | |||
| API Changes: | |||
Description
In a number of situations, it's useful to be able to search field values that contain a certain word, not just a certain string (as ~= does). The distinction is essentially a word boundary regex versus an all-inclusive regex. That is, I'd like to be able search like this:
.*\bmyvalue\b.*
where \b is a "word boundary" as defined by the PCRE standards. Right now, using ~=, I can only search like this:
.*myvalue.*
The most pressing use case for such a facility (at least for my projects) is support for "subticket keywords", an extremely flexible technique of associating one ticket with another by using the TracLinks conventions in the keyword field.
For example, to associate a new ticket as a "subticket" of ticket:13, I place #13 in its keyword field. Currently, this can later be extracted with a TracQuery such as [[TracQuery(keywords~=#13)]] however this incorrectly matches #130, #131, and so on. Thus, a word boundary match operator was suggested by Remy Blank later in the same thread.
At first blush, it seems that the TracQuery "mini language" is actually implemented with simple ANSI SQL-based wildcards, which makes implementing word boundary matches non-trivial. I'd imagine one might have to wrap a call to Query.execute that catches the results of a ~= query and then filters these results further (possibly with a decorator?).
Attachments
Change History
comment:1 Changed 3 years ago by osimons
comment:2 Changed 3 years ago by rblank
- Milestone set to 2.0
comment:3 Changed 22 months ago by cboos
- Milestone changed from 2.0 to unscheduled
Milestone 2.0 deleted
comment:4 Changed 22 months ago by Carsten Klein <carsten.klein@…>
see also #8914 for a patch that would allow regular expression matching for all of the available backends.
comment:5 Changed 20 months ago by cboos
- Keywords keywords exact match added
- Milestone changed from triaging to next-major-0.1X
- Priority changed from normal to low
- Severity changed from major to minor
#9466 was closed as duplicate.
Note that for the specific use case of "subtickets" described above, this could be handled easily by adopting a slightly different convention: instead of referencing #13, you could add #13. for example, and there would be no false positive ("real" SubTickets support will eventually involve a numbering scheme corresponding to #13.1, #13.2, #13.2.1 etc.).
comment:6 Changed 16 months ago by Mitar
- Cc mmitar@… added



#7374 closed as duplicate.