isNullorEmpty

Question

Hi,

For the above expression rule, if I try to add a!isNullorEmpty(local!ID), then I can getting false, but I am expecting true. 
 Am I doing anything wrong here.

ajhick · Answer

Yes, see below code and screenshot for the difference. It's subtle but technically a list containing all null indexes, even if that's a single index, isn't actually empty. This is good that this happens! 
 To get the behavior you want you can either reject all nulls from the list or cast to the scalar (single) integer data type. Both behaviors are demonstrated below. 
 
 a!localVariables(
 local!nullInteger: tointeger(
 null
 ),
 local!listOfNullInteger: cast(
 a!listType(1),
 local!nullInteger
 ),
 local!rejectNulls: reject(
 fn!isnull,
 local!listOfNullInteger
 ),
 local!castToScalarInteger: cast(
 typeof(1),
 local!listOfNullInteger
 ),
 {
 nullInteger: a!isNullOrEmpty(local!nullInteger),
 listOfNullInteger: a!isNullOrEmpty(local!listOfNullInteger),
 rejectNulls: a!isNullOrEmpty(local!rejectNulls),
 castToScalarInteger: a!isNullOrEmpty(local!castToScalarInteger)
 }
)

Harshit Bumb (Appyzie) · Answer

Try using flatten before a!isnullOrEmpty(). Also, for future use, always create your own null checks. In that, you can loop through the input and check every item for null. This way, you can add all the conditions which should return null in the same rule.

Dave Lewis · Answer

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.

Mike Schmitt · Answer

a!isNullOrEmpty() seemingly fails , specifically on the condition of "array containing one null value". This may be the intended behavior, actually, even if it's a little bit unintuitive. The thing you need to remember is that QueryEntity will return list-type data as a result (presuming that's what your query attempts to do), and then using "index()" to get a property from a list of dictionary will still return list-typed data (hence your result type still being "list of number"). 
 [BTW, I still recommend using the "property()" rule instead of "index()" to get a property (as opposed to an index, since that term means the indexed position of an array), but that's just me being pedantic here. the only impact this has is on code clarity/readability, since the two rules are aliases for each other.]

Mike Schmitt · Answer

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.

isNullorEmpty

Top Replies