isNullorEmpty

Another possibility could be the all() function.  all(fn!isNull, local!ID)

Sometimes the old looping functions still have a use.  In this case, that's pretty succinct if it works.

Another possibility could be the all() function.  all(fn!isNull, local!ID)

Sometimes the old looping functions still have a use.  In this case, that's pretty succinct if it works.

I believe the focus shouldn't be on "fixing" a!isNullOrEmpty() when it isn't the issue. The issue is the query returns a list but is being treated like a scalar value. So focus on the actual issue. Cast the query response to a scalar data type (which was one of the solutions in my original response) and the problem (which isn't actually a problem) goes away.

Sure, what you've proposed will work. But is ignoring what the actual issue is and may lead people to believing that a!isNullOrEmpty() isn't working as it should and therefore using the fix you've proposed ubiquitously without thought as to WHY a!isNullOrEmpty() was returning false and potentially misusing it.

It's a very niche edge case though!

I think that using "orEmpty" as in isNullOrEmpty does a great deal to imply the poster's original intent that he does want to consider the case of an empty set, and therefore IS NOT treating it as merely a scalar.

What we need to consider is the 3rd possiblity, and indeed a 4th possibility also.  There's the possibility of a null, an empty set, a set of results that are all null, and also a set of results that are all empty:

null, {}, {null, null, null}, and {{}, {}, {}}

All 4 need to be addressed appropriately as they come up.  It appears the poster's intent for the third possibility and likely the fourth as well is to treat them the same as the first and second possibilities are already treated.  Assuming this, we present possible solutions for doing this.  I leave it for the original author of this thread to share if any worked or if our assumptions about his or her intentions are mistaken.

ajhick said:

The issue is the query returns a list but is being treated like a scalar value.

I also think part of the issue here is that the user is expecting a single value to be returned from the query (unless i'm inferring incorrectly from their partial code), but they're not taking the necessary steps to make the returned result type "singular" before dealing with it.

For instance, I often add an "index( [....], 1)" wrapper around my queries where i expect the value to always be "one and only one", both to disambiguate the code for future readers, as well as to make sure i don't get any surprised later on in the interface when i forget to deal with it like an array of one instead of a single value.