Index() or dot notation?

Certified Lead Developer

Hi All,

I just wanted to know what's Appian best practices when it comes to retrieving data from a data subset. Should I index into the data subset or use dot notation? I noticed that when I use index() it doesn't throw an error for a null result set but does throws an error if I use dot notation. I know dot notation would cause a pink screen error on the tempo interface but debugging this would be quite simple since we know exactly where the error is coming from. For index(), this wont throw an error on tempo but will be harder to debug and would be a silent fail if a user doesn't raise the issue that that data is coming null when it shouldn't. 

  Discussion posts and replies are publicly visible

Parents
  • Certified Senior Developer
    The best practice would be use index() function instead of dot operator. we can check null condition for exception handling.
  • Why would you receive a null error? This only happens if your CDT is the wrong type, such as Variant or List of Variant or another type altogether. Instead, you should fix Variant errors upstream as possible. This happens most commonly when retrieving the "data" element of a DataSubset which is always a List of Variant. On our project we built a custom wrapper for queryEntity() that casts the data to the desired CDT type, just like legacy Query Rules used to, which avoids the Variant indexing errors. Variants cause many problems in Appian, so fixing the problem at the root is more impactful.

     

    To demonstrate what I mean, if you evaluate topaginginfo(null,1).startIndex you do not get an error. You get: null (Integer).

  • Acknowledging that syntax preferences exist, here is the documented recommendation directly from Appian (link: Expressions)

    "Note: Appian recommends using index() to access the index value of a CDT in cases where the variable may have a null value, or the field name is not available."

    If you have something that's effectively a variant/any datatype, then if the property doesn't exist / or is the wrong type on that object, dot notation will give you an error.

    For any object that's strongly typed - for instance as a rule input - that situation won't occur. As long as you're typesafe you can enjoy dot notation.

    One of the key benefits of dot notation is that it makes your SAIL code smaller and so much more readable.

  • The easiest example of a case where it's necessary is the results of a!queryEntity where the possibility exists that the resulting query data set will contain zero rows (i.e. an empty set).  It's usually not worth the trouble of hard-typecasting query results, in which case, trying to refer to local!queryResult.data.objectId will result in an error if the query was empty, but using property(local!queryResult.data, "objectId", null()) would work safely.

    (Note: I still personally insist on using property() for CDT properties, and reserve index() for indexes, as I noted already in a different comment in this very-old post).

Reply
  • The easiest example of a case where it's necessary is the results of a!queryEntity where the possibility exists that the resulting query data set will contain zero rows (i.e. an empty set).  It's usually not worth the trouble of hard-typecasting query results, in which case, trying to refer to local!queryResult.data.objectId will result in an error if the query was empty, but using property(local!queryResult.data, "objectId", null()) would work safely.

    (Note: I still personally insist on using property() for CDT properties, and reserve index() for indexes, as I noted already in a different comment in this very-old post).

Children
No Data