New TracQuery match operator for "contains the word" would be useful

[meitarm@…]

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?).

[osimons]

#7374 closed as duplicate.

[Christian Boos]

Milestone 2.0 deleted

[Carsten Klein <carsten.klein@…>]

see also #8914 for a patch that would allow regular expression matching for all of the available backends.

[Christian Boos]

#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.).

[ryandesign]

So, what's up? This ticket and the related and duplicate tickets date back over 11 years. When can we have a method in Trac for searching for complete words in the keywords field? I don't care what the method is as long as I can express it as a search query that I can include in a ticket.