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
    

[jaybodra]

the “in” operator return true if there a property with null value. and if you further check for sub-child it errors out.

example 1:-
$:{
child:null
}

example 2:-
$: {
child: {
child1: “some value”
}

$.hasOwnProperty() helps in filtering this type of use cause while “in” operator return true for example-1, (‘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.

get() method works for both the case in order to filter out property based on null try this: ($.get(“child”) != null) && ($.child.get(“child1”) != null). Is “in” operator (shorthand for get()) bugged ?

---

Get method:

Checking for optional properties and returning defaults in the expression language Designing Pipelines

With the Summer 2017 release there have been a couple of enhancements to the expression language to make it easier to check for the existence of properties in an object and returning a default value. Previously, you could use the ‘hasOwnProperty()’ method to check if a property is in an object. Now, objects have a ‘get()’ method to get the value of a property with the given name or return a default value. For example, to get the value of the property named ‘optional’, you can do: $.get('opti…

---

Sorry for bad formatting.

[nganapathiraju]

jaybodra:

$.hasOwnProperty() helps in filtering this type of use cause while “in” operator return true for example-1, (‘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.

Your expression should be

 'child' in $ && 'child1' in $child

The above will return true is child1 exists in child. Its not $.child

Hope that makes sense.

[jaybodra]

isn’t this expression $.child compliant with java script?

[tstack]

jaybodra:

isn’t this expression $.child compliant with java script?

Yes, “$.child”, “$child”, and “$[‘child’]” all mean the same thing in the expression language, which is to get the value of the property named “child”. The “$” symbol refers to the input document, so “$.child” and “$[‘child’]” mean lookup “child” in the document. The “$child” syntax (i.e. no dot) is a shorthand that is accepted.