Fixing warnings in pipeline executions

[tstack]

With the Summer 2017 release you may see pipeline executions in the Dashboard listing with the following warning symbol in the status column:

This warning symbol indicates that a potential issue has been found during the execution and it may need some attention. It does not mean that anything is seriously wrong. The execution should finish as it once did. The warnings are there to help you and us to update your pipeline to make it perform better. To find out what issues were discovered, you can open the Pipeline Execution Statistics dialog and scroll through the list of Snaps to see which ones have a warning attached. For example, if your execution was using the deprecated Join Snap, you would see the following message:

Other warnings are related to expression language usage, so you will need to examine the Snap’s configuration to find the expression property that the warning is complaining about. Note that if a child execution has a warning, the parent execution will also have the warning symbol. So, you may need to expand the parent execution in the dashboard to see which child execution has the warning.

The current set of warnings are mostly concerned with deprecated functionality and expression language behavior that deviates from the JavaScript standard.

• Deprecated Snaps - Snaps that are no longer maintained or have been replaced will be marked with this warning. Most likely you are seeing this message for a Join Snap. You can update the Snap by opening the pipeline in Designer, dragging a new Join Snap onto the canvas, copying the properties from the older Snap instance to the newer one, and then replacing the old instance.

• toLocaleDateTimeString()/toLocaleDateString()/toLocaleTimeString() was passed a string argument - These functions initially took a JSON-encoded string as an argument instead of an object. Since parsing the JSON string is slow, we wanted to warn about the potential performance hit and to bring people closer to the JavaScript standard. Fixing the warning should just be a matter of removing the outer quotes since the JSON object will treated as an object literal. For example:

  $date.toLocaleDateString('{"format":"MM-dd-yyyy"}') // Generates warning
  $date.toLocaleDateString({"format":"MM-dd-yyyy"}) // No warning
  

• hasOwnProperty() usage - This method deviated from the JavaScript standard in a few ways, which can cause confusion for people familiar with the language. To make you aware of these differences, we have added the following warning messages:

  • “You must explicitly check for a null value” - If the property being tested for was in the object, but had a value of null, the method would return false instead of true. To fix this warning, see this topic for some new ways to check for the existence of a property and get a default value.
  • “Use hasOwnProperty() for each component of the path” - The argument to this method was treated as a JSON-Path instead of a plain property name, which can cause problems if the property name has a dot in it. To fix the warning, you will need to check for each component in the path. For example:

    $.hasOwnProperty('$.child.value') // Generates warning
    
     // No warning, use if '$child' is not guaranteed to exist
    ('child' in $) && ('value' in $child)
     // No warning and '$child' is always expected to be there
    'value' in $child
    

[tstack]

jaybodra:

the “in” operator return true if there a property with null value.

Yes, the “in” operator only tests to see if the property is in the object and not what it’s value might be. If the “child” property can be null in your data, you would have to check for that as well, by doing something like the following:

('child' in $) && $child && ('value' in $child)

Which is, admittedly, ugly. However, I’m not really sure how common this would really be, so I imagine most expressions would not have to do such a thing.

Still, this calls for some solution and I think we would prefer to modify the jsonPath() function to support default values instead of changing the hasOwnProperty() in a way that deviates from the standard.

jaybodra:

(‘child’ in $) and will generate an error “Requires an Array or Object in-the-Right-hand-side” for example-1 if you try this expression: (‘child’ in $) && (‘child1’ in $.child) but it will work for example 2.

The failure comes from “(‘child1’ in $.child)” since “$.child” is null, which matches the JavaScript behavior.

[jaybodra]

@tstack Thank you so much.