Developer Warning or other feedback when accessing Server lists
117
Views
5
Comments
New
OutSystems UI

When an output of a data action or aggregate is of type list and is passed to a server action, only the current value of it is sent.  This is an optimization / behaviour that defies user expectation. In particular it is different than the expected behaviour for example when using local variables of type list where all the elements in the list are transmitted to the server.

I think this is a reasonable optimization under most circumstance.  However, there is no warning to the developer when accessing the list as a list.  This can lead to unexpected behaviour that the user has to debug even when their code is proper.

Suggestions for possible remediation:

  1. Generate a warning when this is the case; or,
  2. Don't return a list type, just a single value; or,
  3. During compile time check to see if the code is accessing the list and if so, return the whole list.

I'm open to any solution other than silently acting list a list but only having a single value with no indication to the user that the other values have mysteriously disappeared and the code will not function as expected.

Re: Case #2813379.





 

I tried to recreate the issue you are reporting, but cannot recreate it.

You cannot add a file to an Idea comment, but please create a forum question about this?
Could you add a sample application file (and/or provide screenshots of what you set as the input parameters to the server action?)

Here is a link from my original bug submission that has an OAP file:

Bug Example

Output from the project:

In the LoadStructFromPretendDB after fetch there are 5 children.

You can see this clearly in the serialization:

 {"children":[{"param":"child 1"},{"param":"child 2"},{"param":"child 3"},{"param":"child 4"},{"param":"child 5"}]}


---- However, when I read the number of children from the Other Sources / Server Code (AccessStructFromOtherSources) I read only 1 children.

But we can clearly see above in the JS/client that there are still 5 children.

And the server side serialization shows that the data is missing: 

{"children":[{"param":"child 1"}]}


---- BUT! When I read the number of children in Other Sources from a screen variable I get the proper number: 5 children.

And the serialization shows that the data is proper: 

{"children":[{"param":"child 1"},{"param":"child 2"},{"param":"child 3"},{"param":"child 4"},{"param":"child 5"}]}


---- The expectation is that when I am reading Step1_LoadStructFromPretendDB.myStruct that the data is consistent whether I'm reading that data from Client or Server side.

As I am not included in your developer team, I cannot access the file you are referring to.

It is available only to the persons allowed to view the support ticket.

If you already have answers in the support ticket, or someone from OutSystems looking at it, then I would suggest this idea to put on hold, until you have an answer. Then you can report here the progress/answer.

If this idea was created because someone in the support ticket suggested to create an idea for it, then please, do share some more information/screenshots. Or even better, create a forum question where you upload a sample project (with only the functionality the issue you are having, with example/test data).

Sorry about that.  I'll just describe it as I should have originally :-)

We have a screen, as per the screenshot below:

The structures are defined as below:

MainStruct is a list of ChildStruct.  ChildStruct is simply a 'param' of type text.  The specifics don't really matter other than the MainStruct contains a list.

Reproduction steps:

In the Data Action Step 1 above myStruct is populated.  It could be from a database, or from the output of some method.  Specifics don't matter.  What matters is the nested structure.  Serialized output of myStruct:

{"children":[{"param":"child 1"},{"param":"child 2"},{"param":"child 3"},{"param":"child 4"},{"param":"child 5"}]}  

If you access myStruct from a Client Action everything works as expected.


In the Data Action Step 2 it will not work as expected.  Step 2 Data Action simply reads myStruct from Data Action Step 1 and serializes it and saves it to an output parameter.  If then in a Client Action you display the output, you will see the following:

{"children":[{"param":"child 1"}]} 

That is the optimization I'm talking about.  Because Step 2 is a Data Action, and it's reading content from Step 1 (another Data Action) OutSystems will silently optimize and only return the first item in the list.  I contacted support and this is expected behaviour, it's simply not documented.

This is totally not obvious to the developer.  This is why I recommend at minimum that a warning be presented to the user at compile time.


As a final Data Action Step 3: Sometime before you call that Data Action, use a  a Client Action to copy myStruct from Step 1 to a variable (e.g. copiedStruct) and then access copiedStruct from another Data Action then it will work as expected:

"children":[{"param":"child 1"},{"param":"child 2"},{"param":"child 3"},{"param":"child 4"},{"param":"child 5"}]} 


To summarize, if you access the output of a Data Action from another Data Action, and part of that output is a list, it will only give you access to the first item of the list.

Thank you for your extensive step-by-step recreation. This way I can confirm: when using the structure as you defined, using the output of a data action within the next data action does get trimmed/optimized.

No warnings when directly assigning the output of data action step 1 to be used in data action step 2. Executing the step 2 data action results in using only the first-child info of the struct returned by the step 1 data action. Other child-items are not known (even though I hard-coded 5 child items as the step 1 data action output structure)

The only workarounds I can think of are:
- As you've stated in your Step 3 description: by using a local variable on screen level that gets assigned somewhere after the first data action has run, using that local variable in the next data action
- executing multiple steps within one data-action, where you have the data available in full

Anyhow, you receive my +1 on this idea, because this behavior is (also in my opinion) not consistent and does not inform the developer this will be optimized/trimmed.