On 11-8-2014 19:45, Alex Vandiver wrote: > On 08/10/2014 07:53 PM, Jeff Blaine wrote: >> [ "I ran a search with StatementLogging enabled and this ] >> [ is the sql statement with "content not like 'foo.com'" ] >> [ and "content like 'foo.com'", they are the same." ] >> [ --Thanks for that, Joop! ] >> >> Alex, to be clear, these queries below were done via the search >> form. I am only quoting the SearchBuilder terms for simplicity. >> >> The form stated: >> >> [ Content ] [ matches ] __foo.com_______ >> >> And >> >> [ Content ] [ doesn't match ] __foo.com_______ >> >> and I clicked search to get the same 3 tickets as results for both. >> >> I can't see how, in some way or another, this is not a bug. > "Content doesn't match" indeed uses the same codepath as "content does > match." The problem is that not all of the FTS backends support "NOT > MATCH" -- and for those that do, it likely doesn't do what you expect. > I can guarantee that for any particular phrase, there exists one > transaction on the ticket which does not contain that phrase -- thus > always matching all tickets. > > Running the query from the statementlog and modifying as described (adding a not) does what it needs todo, exclude all tickets that have that phrase in it. This is using Pg as a backend. Oracle works too. Mysql I don't know because I don't use it for RT.
Joop -- RT Training - Boston, September 9-10 http://bestpractical.com/training
