182
Views
9
Comments
Solved
Unexpected behaviour comparing two elements of the same structure
Question
Application Type
Reactive
Service Studio Version
11.53.38 (Build 61903)
Platform Version
11.18.1 (Build 37828)

Hi,

I am having a situation that I simply cannot explain. Comparing 2 elements that are based on the same structure do not result in the expected result.

I have a screen where I retrieve data in a data-action and that data is copied to a local variable in the after-fetch:
In my screen I have switch that is based on the lclRecord.SomeBoolean value. There is an On Change-event "validate" that fires when I flip the switch.
I've created some different checks:


Initially the value of SomeBoolean is set to False.
After flipping the switch and back again and check the logs I see this:

So first the boolean is changed from false to true;

  1. The checks on the attribute within the element are correct;
  2. The checks on the whole element (i.e. the structure) are also correct
    No problem up until now.

Then the boolean is set to false again:

  1. The checks on the attribute within the element are correct;
  2. The check whether the lclrecord is equal to the outSomeData is also correct (there is no change so they are equal)
  3. But then... The check whether the lclrecord is different from the outSomeData is also set to true; HOW IS THAT POSSIBLE? It is both equal and different..?
  4. And for the record; the last check not equal does result in the expected false. 

Debugging does tell me that the values in the elements are equal (sorry don't have a screenshot of that)
Also converting the elements to JSON and comparing those does result in the correct true or false in the various checks.

So there you go; my question is: Why is both a=b and a<>b resulting in a true...
Is this a bug or am I overlooking something?


Looking forward to any respons, with regards,
Rogier Fluitsma

RogiersTestcase.oml
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
Solution

In general, do not compare two records as a whole. I cannot explain why you get these results specifically, but there's a lot of marshalling going on with lists and records that affect their equalness. Also, for client-side comparison there's JavaScript that may have some iffy rules for equality (== vs. === for example), so to be on the safe side: always compare indiviual attributes!

UserImage.jpg
Rogier Fluitsma

Whilst it is not really the answer I was hoping for, I do understand your reasoning. Especially the == vs. === does make sense.

For my current situation comparing each individual attribute is not desirable; as I have 20+ attributes in there.

What I will do is keep the JSONserialize approach; convert both the DataAction1.OutSomeData and the lclRecord and compare the JSON-strings; a text-comparison should not fail really.

2020-09-15 13-07-23
Kilian Hekhuis
 
MVP

Yeah, the JSONSerialize approach should work. Be sure to report this bug to OutSystems support, so they can analyze it and perhaps fix it.

2021-09-06 15-09-53
Dorine Boudry
 
MVP

Oke,

interesting observation.

It is not related to switching, though, just add your validate at the end of the OnAfterFetch, and you will see that there is ALWAYS a difference between "not (x = y)"  and "x <> y"

Maybe this is a know feature, that <> should not be used for comparing structured data ??  Anyone ?

Dorine

2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
Solution

In general, do not compare two records as a whole. I cannot explain why you get these results specifically, but there's a lot of marshalling going on with lists and records that affect their equalness. Also, for client-side comparison there's JavaScript that may have some iffy rules for equality (== vs. === for example), so to be on the safe side: always compare indiviual attributes!

UserImage.jpg
Rogier Fluitsma

Whilst it is not really the answer I was hoping for, I do understand your reasoning. Especially the == vs. === does make sense.

For my current situation comparing each individual attribute is not desirable; as I have 20+ attributes in there.

What I will do is keep the JSONserialize approach; convert both the DataAction1.OutSomeData and the lclRecord and compare the JSON-strings; a text-comparison should not fail really.

2020-09-15 13-07-23
Kilian Hekhuis
 
MVP

Yeah, the JSONSerialize approach should work. Be sure to report this bug to OutSystems support, so they can analyze it and perhaps fix it.

2022-07-11 14-05-36
Jeroen Barnhoorn

I ran into the same problem, so I took a look at the underlying JavaScript code that OutSystems generated.

What I found is that when using the = operator to compare two structure in a client-side action, a deep comparison is done (i.e. comparing the value of each individual attribute of the structure), thus giving the expected result.

When using the <> operator on the other hand, OutSystems simply compares the two objects using the !== JavaScript operator. Since we are comparing non-primitive data types, this results in a comparison by reference. In other words: it will only look at the memory location and not at the information stored in the object. Therefore, it will say that your two structures are different (because they're stored in a different location), while in fact they are exactly identical (in terms of information contained).

In short: it is perfectly fine to use the = operator to compare two structures, but the <> operator should be avoided when comparing structures in client-side actions. Instead, you can use the = operator and then invert the result using the not operator.

2021-09-06 15-09-53
Dorine Boudry
 
MVP

great information, thanks @Jeroen Barnhoorn 

2020-09-15 13-07-23
Kilian Hekhuis
 
MVP

@Jeroen Barnhoorn can you also create an issue for this with OS Support? OutSystems should be notified of this (imho) bug.

UserImage.jpg
Rogier Fluitsma

I am fairly certain I did when I encountered this issue last year.

Edit: https://www.outsystems.com/SPP_Ticket_UI/Problem_Detail?CaseId=2783986&ProblemId=RPM-3749

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.