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.
Discussion posts and replies are publicly visible
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.]
Obviously I can't speak for Appian but from my perspective it *should* work this way, as in a!isNullOrEmpty() is not failing. A list of null isn't empty, null is a perfectly reasonable "value" to return. There's a massive difference between null being return (eg. Nothing was found) and a list of null being returned (Eg. Things were found and the value(s) were null).
I fully agree that queries returning a single record returning as lists can be problematic, but that's not an issue with a!isNullOrEmpty(). I also haven't fully thought about why queries would return lists, there may be a good reason...or maybe not! Maybe if the entity being queried is a primary key or has a unique constraint and the "=" operator is used then Appian could be smart enough to not return it as a list.
Not sure, but either way, a!isNullOrEmpty() is working as far as I expect it should. This is not a blind defence of bad functionality either, I have use cases where I want a!isNullOrEmpty() to return false when given a list of null, even when that list contains only one element.
And if the intended behaviour is to check if every element in an array is null then we have the tools at our disposal to do so. Best of both worlds!
Right. I do think that there's a massive difference between an empty shopping bag, and a shopping bag containing an empty shopping bag (especially if the shopping bag in your shopping bag has a price tag on it). Likewise, a massive difference between a lunchbox with nothing in it and a lunchbox with an empty thermos in it. Especially on ebay.
It absolutely should make a distinction between returning no results and returning some results that happen to be empty or null. Nothing is interesting. A set of 4 nulls is interesting in a completely different way.
Mike and I are just striking up an old conversation about how index() should be for indeces and property() should be for properties. a!update() is amazing, but it's a bad sign that the keyword for the property you want to alter is "index:". Amiright?
I find myself agreeing with Mike (and you) on that front but not changing my behaviour. I tried about 6 months back...but then I forget and keep using index() anyway. I've used it for so long that my brain handles it being a number or a field name just as easily. I've also never had a Production incident or a personal issue in developing caused by using index() so personally it's a "solution" to a problem I don't have.
But I'm also fine if property() was just removed. Traditionally I guess in computer science the index refers to the integer value but as far as I know that's just convention. There's nothing about the concept of index that says it has to be an integer value. But conventions are useful so...yeah. /shrug
ajhick said: I've also never had a Production incident or a personal issue
The current production system I inherited has some (thankfully somewhat rare) instances where there are 5-or-6-layer-deep nested index() calls where it's an arbitrary mixture between indexes and properties.
That's just annoying!