Can anyone explain these bizarre search results against Sprint?

[Justin Merrow]

I've been trying to figure out why some issues aren't appearing in a search results set, as I would expect - and I came across the following bizarre search results that I'm having trouble figuring out:

QUERY                                                  RESULTS
project = C2C                                            934
project = C2C AND Sprint = 13542           61
project = C2C AND Sprint != 13542        328

Not to state the obvious, but the combined results of queries 2 and 3 should equal the results of query 1 - but aren't even close.

Why would this be happening?  It seems like an issue in the project should either be in Sprint 13542 or not in Sprint 13542 - but these results imply there are quite a few issues that don't fit either category.

Any ideas?

Thank you!

[Jack Nolddor _Sweet Bananas_ · Accepted solution]

Hi Justin and welcome,

At first JQL can be really tricky, just an example:

project = C2C AND Sprint != 13542

Above filters means any issue on project C2C having an Sprint set different from 13542

However...

project = C2C AND ( Sprint != 13542 OR Sprint is EMPTY)

What you are really looking for! Any issue on project C2C having any Sprint set different from 13542 or not having Sprint at all.

[Justin Merrow]

Thank you!  Thank you!  That is obviously the exact problem.  I've run into that in the past, but it had slipped my mind.

Thanks again for your quick reply and your helpful insight!  I really appreciate the help!

Justin

[Nic Brough -Adaptavist-]

I suspect you'll find the missing items have no sprint.

It's an odd point of logic that humans get wrong all the time (totally understandably, it's just not the way we think)

Let's translate those clauses into plain English and expand on it

Project = C2C - "The issue is in project C2C"

And Sprint = 13542 - "and in sprint 1352"

Those two work fine for both the computer and the human, the sticking point is that humans drop the part of the question a computer needs when you ask

and sprint != 13542 - this looks like "the sprint field is not 13542", but there's a hole.  If the field is empty, it's not not 13542, it's not anything at all.  The logic has nothing to compare with.  So it doesn't find it  If the field is null, you cannot actuall say that it is not 13542, because you don't have anything to look at.

The way the human brain tends to process "not" is logically incorrect.  

Anyway, I would expect this to do what you expect:

project = C2C AND (Sprint != 13542 or Sprint is empty)

[Jack Nolddor _Sweet Bananas_]

In fact, null != 13542 in almost any language code, no idea why that odd implementation but the is EMPTY part is both confusing and unnecessary from my point of view.

And only leads on people errors... like this.

[Nic Brough -Adaptavist-]

Not really, think of java as an obvious example:

• Is X = Y?  You get a true/false
• Is X != Y?  You get a true/false
• Is null = Y?  You get an error

It is logically obscure, but it has uses.  In coding terms, it is often very important to understand that a yes/no question has three possible responses.