We’ve had recurrent feedback from our developer community that we should aim for a simpler definition of generic lists. For example, to create a list of integers you would need to create a structure that contained a single integer attribute.
This represented a relatively large change in the way we deal with lists, but since it had such a wide impact on your productivity, we decided that with OutSystems Platform 9, we would incrementally improve our type system. And we didn’t want to wait for a major version release to share such an awesome feature with you, so we continued to evolve it. As that evolution came to a natural cut-over point, we deprecated the “old” way of doing it.
So:
If you were used to working with Record Lists, worry not, things aren’t that different now. Let’s check how using Lists is different than Record Lists:
From 9.0 onwards, you can create lists of integers, lists of text, or a list of any other basic type. And it’s as easy as with other programming languages.
To create a list of integers, create a new variable and:
That’s simple right? And that wasn’t possible with Record Lists.
Creating a list of a single compound type like Entity or Structure, was already supported before 9.0.
Until 9.0.0.0, if you wanted to create a list of users, you would create a new variable and:
Now with the List data type, things haven’t changed much. To create a List of Users, you create a new variable and:
The awesome part is that now to access the user’s name, instead of writing Users.Current.User.Name, you can just write Users.Current.Name.
Users.Current.User.Name
Users.Current.Name
I’ll grant you that this doesn’t seem much for the User entity. But in situations where the names of your Entities, Structures, and Attributes are long, this will save you a few keystrokes and is easier to read.
Oh, and you’ll notice that we’ve also updated the defaults. So, if you name your variable ‘Users’, we automatically define it as being a List of Users.
Sometimes, it’s also handy to define a list of multiple Entities and Structures.
Until 9.0.0.36, to define a list of users and cities you would create a new variable and:
Starting on 9.0.0.36, you can define a List of Users and Cities. Create a new variable and:
Just like for Record Lists, to access the user name of this List, we can use Users.Current.User.Name
And since this approach is more generic, we can even define a List of Users and a Boolean, which we couldn’t define using Record Lists.
When you’re fetching data using Aggregates, they’ll always return a List of Record (just like above). This is because your Aggregates can have calculated or aggregated columns, so they can’t return a list of integers or a list of Entity/Structure.
So if you want to return the result of an Aggregate that fetches users, you might be tempted to define the output parameter as a User List, when in fact you need to define it as a List of Record of User.
Or you can do it the simple way, choosing the suggestion OutSystems Platform gives you.
Can you use records as the datta type for an item attribute? Or do I have to create lists in the database using normalized tables?
Hi Jeffrey,
I'm not sure what you mean. A record is an in-memory collection of different data types, especially structures. They don't live inside databases.
(Also, your post has little to do with the topic of this thread, and this thread is more than 1.5 years old. Next time please start a new topic.)
Hi João Fernandes,
Regarding to your original post, it was about version 9.0 (specifically 9.0.0.36) and it explained some "not so obvious gotchas - Aggregates" and the need to use a data type of "List of Record of <Type>".
I was now testing on my personal environment, version 10.0.603.0, and it seems that those gotchas have gone away, in the sense that now it's not mandatory to define the variable of an output parameter (that it will be assigned the result of an Aggregate) as a "List of Record of User" but we can now just simple use "List of User" and it will be accepted. Do you confirm? If so, in which version was this introduced?
Cheers,
Tiago Bernardo
Hi Tiago,
Iirc automatic conversion of Record Lists to simple Lists and vice versa was introduced in 10, together with nifty features like mapping of structure Attributes. The downside of this is that it's less clear that the list is copied, instead of just assigned by reference, so there's a slight performance penalty.
Refering to Mr Kilian Hekhuis's response above
(Also, your post has little to do with the topic of this thread, and this thread is more than 1.5 years old. Next time please start a new topic.)----------------------------------------------
So Technically There is no difference between using List Type (for aggregate output) or using new Structure + including entity and other basic datatypes (thus a complex type)
Rather I find the it an advantage to use a structure for complex type as it has an advantage from re-usability perspective...Am I correct from re-usability perspective? Cheers,Manjunath
Hi Manjunath,
The output of Aggregates is always a Record List. Records can contain Entity Records, structures and simple types:
The output of an Aggregate will be Entity Records only, unless you add Attributes, which will be of simple type (never structures). The output of an SQL statement can be Entity Records and structures, but not simple types (mainly for historical reasons).
As for reusability, that heavily depends on your use case, so it's difficult giving an opinion about that without knowing what you intend to do and why.
Regarding your question about reusability. Having a User List or a User Record List is mainly a matter of style, as the platform converts between both types seamlessly. One could argue that a User List is simpler in use and readability, in that we can access elements with ListVar.Current.Name, instead of ListVar.Current.User.Name.
As for using Records vs Structures, the main guideline has to do with the first being anonymous. As a rule of thumb, if you want to reuse a data type consistently on a given API, you should use a Structure. Records should be used mainly in specialized scenarios, where reuse is not expected or has a very limited scope (like storing the result of an Aggregate), since adding a new attribute implies going to all usages and updating the data type.
So, summing up, Records give flexibility, but Structures give reusability.
Paulo
Why in Integration Studio is not possible yet to create a extension that have a List of (Text, Integer...) ? We still need use a Record and a Record List.