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. Can you explain your use case a bit? I expect that you meant it as "exclude tickets which do contain"? I expect we should, at least in the short term, document that "CONTENT NOT LIKE" is not supported, and make it return the empty set. - Alex -- RT Training - Boston, September 9-10 http://bestpractical.com/training
