BUG FOUND: Service Studio, Sorting Order By value is not getting updated

BUG FOUND: Service Studio, Sorting Order By value is not getting updated


Service Studio, Sorting Order By value is not getting updated (when the entity name is modified).

This causes the following error

'User' found in 'Order By' parameter is an invalid Entity

I wouldn't call this a bug. List_SortColumn is just a function, and "{User}.[...]" just a Text parameter. How is Service Studio to know it contains the name of a table you just renamed?

Kilian Hekhuis wrote:

I wouldn't call this a bug. List_SortColumn is just a function, and "{User}.[...]" just a Text parameter. How is Service Studio to know it contains the name of a table you just renamed?

All elements are stored in the xml file (dot oml), they are assigned a key which is used to track elements and any changes you make 

It's possible for otsystems to track changes, just like when you rename an entity, outsystems would automatically updates the interface order list elements.


What you say is correct, but doesn't address what I wrote: Service Studio cannot reasonably know that a certain text string contains a table name. It's the same for injected dynamic SQL.

I agree with Kilian, this doesn't really seem like a bug. No IDE that I know tracks element name changes when they are just a string parameter. For instance, in Visual Studio, if you rename a form control, references to it are updated in the code, but not if they are just a string parameter to a method.

I disagree! there is a possibility.

Firstly there is a difference between tracking user code written in traditional c# or JAVA vs tracking code changes written in a visual development environment where code is written in a controlled widget and validated and auto-generated by the platform.

Outsystems code is controlled in outsystems environment, there is only a specify way to fill in certain properties - i.e You can not write custom SQL in an "Aggregate" widget either (and this widget is what I am referring to).

Every element you create in service studio is tracked and assigned a unique key (SS_KEY), the file is then saved in an XML file, known as OML outsystems markup language  (this also includes your aggregate sort text string and List_SortColumn text string etc). 

Lets take an example, when you rename an entity name, Service studio looks at the xml code and finds where the entity is referenced,  it then makes the required necessary changes. Just like when you rename an entity name and suddenly, you notice the text string value of the column property is automatically updated via "RichWidgets\List_SortColumn" (the same can be achieved by updating the text string sort property of a aggregate widget).


Nobody's saying it is not possible at all, but you claim it's a bug, and that's simply not true. It's a feature you want, so add an Idea.

Also, you seem to think that because the function is in the aggregate, it's part of the aggregate, but that's also not true. There's little (if any) difference in passing the output of the List_SortColumn_GetOrderBy function as a parameter to an Advanced Query/SQL (and a Simple Query pre-P9) and using it in an aggregate: it's evaluated first, then passed as parameter to (or pasted into) the SQL.

Again, the table name is in a text string. This is why it's nigh impossible for an IDE to detect and change it accordingly.


1. This is not a bug.

2. This is BAD, STUPID functionality, because we are using a string literal for data that we normally see True Change "heal".

3. This is *arguably* a bug, because string literals in Advanced SQL *representing the exact same thing* get updated when the data model changes, so it is NOT silly to expect the same thing to work here.

4. There is already an "Idea" on this from a while ago: http://www.outsystems.com/ideas/2583/update-list-sortcolumn-getorderby-table-name-parameter-after-a-change-on-table-na

Bottom line:

Stop arguing about the semantics of "bug" or "not bug", this is done wrong, period, because it breaks the developer's expectation of "I can change an Entity name and things still work". As a result, while it may or may not be *technically* a bug, it is garbage experience for the developer and as such it should be fixed.



"A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways " https://en.m.wikipedia.org/wiki/Software_bug

I expect service studio to work one way but it did not deliver the expected results expected  and hence it is classified as a bug. It delivered a bad and unexpected user experience - self healing test failed. 

Well now, James, in a bad mood? :) I agree the user experience can be enhanced, but I also understand why it's difficult in this case.

Robert, you can't classify everything not working as you'd expect a bug, but as James said, let's not start semantic discussions :).

Kilian Hekhuis :) 

But I do expect self-healing to work in outsystems  only because self heal in outsystems is an expected behaviour (I wouldn't expect c# or Java or any other traditional programming language to self heal because it was not designed to self heal and therefore it is never an expected behaviour to begin with). 

Perception drives expectations, it's how you see it and think of it, maybe I think outsystems is too superior so my expectation of self healing ability is higher than others, If I lowered my standards and think outsystems product is just an average  product then my expectations would also be reduced/lower. 

Either way it's up to outsystems to fix this broken behaviour or not, we can leave it at that. 

Yes, it's a good assumption to start with. The problem is that the List_SortColumn_GetOrderBy is an ugly hack from RichWidgets, which itself is a bit of a mixed bag of Platform add-ons that never really get "real" Platform status. I think the only way to solve this is to allow for some "native" sorting instead of the hack.

Sorting really shouldn't be a string value to begin with, string values are prone to error.