4D v19 R4 is shipped with a new ORDA concept: Aliases. They are the logical and complementary continuation of computed attributes.
This blog post explains what aliases are and highlights their advantages, especially when to use one or the other… or both.
What is an alias?
As the name suggests, an alias is nothing more than a synonym or shortcut to an existing datastore object. Like computed attributes, they are defined in the “entity dataclass”, as we will see later.
This can be, for example, an existing attribute in the dataclass itself, or more often inside another one. Like a computed attribute, an alias is used to reference a scalar value, an entity, or an entity selection.
Aliases or COMPUTED attributes?
You may wonder why you should use aliases when you already have computed attributes available.
The rule is straightforward, and you can apply it without risk:
An alias should be used if no calculation is needed, and the result (scalar, entity, or entity selection) can be expressed as a path.
e.g. fathersDad = father.father
If any calculation has to be performed (capitalization, concatenation, searches, formulas, etc.), it must be a computed attribute.
e.g.: fullname = uppercase (lastname) + firstname
A SIMPLE AND concrete example
Let’s take the classic example of Companies and Employees.
Inside the Employee dataclass, you want a companyName attribute.
Since this is a simple attribute accessible via a path, a simple alias is enough. 4D will optimize searches, queries, and sorts as if the target was used directly.
//Employees Class
Class extends Entity
Alias companyName company.name
In the same way, in the Companies dataclass, you want to access the list of employees (this time, an entity selection); an alias will also be sufficient.
//Companies Class
Class extends Entity
Alias companyEmployees employees
On the other hand, if in the Employee dataclass you want a coworkers attribute (list of employees with the same manager), you will have to create a computed attribute that will be an entity selection () calculated like this:
//Employees Class
Class extends Entity
Function get coworkers()->$entitySelection : cs.Employees
$entitySelection := this.manager.directReports.minus(this)
The same applies to the company table; a computed attribute will be mandatory if you want to display the list of department heads, etc.
Examples WHERE aliases could be used
The following examples will be based on the physical structure described below: People can be students or professors (or both) and teach and learn languages. The Lessons is the center dataclass that links People (teachers and students) and Language.
“Flatten” a table
You wish to hide relationships and make it “as if” the attributes belonged directly to a dataclass rather than to another.
Ex: Rather than using professor.name, student.name and Language.name based on the relation between Lessons, People, and Language, you may prefer to flatten the Lessons dataclass using aliases:
//LessonsEntity Class
Class extends Entity
Alias professorName professor.name
Alias studentName student.name
Alias languageName language.name
This will allow displaying Lessons using direct aliases!
HIDE “N->P” RELATIONS
The Lessons intermediate dataclasses can even be hidden entirely as long as all the relationships are defined.
In the example above, one can define for each person:
-
- the lessons they follow
- the lessons they give
- the students they have (if they offer lessons)
- the professors they have (if they follow lessons)
//PeopleEntity Class
Class extends Entity
// entity selection of followed lessons
Alias followedLessons learning.language
// entity selection of given lessons
Alias givenLessons teaching.language
// entity selection of professors
Alias professors learning.professor
// entity selection of students
Alias students teaching.student
Conclusion
Check out the HDI above and learn more about the use cases of aliases. Also, find more details on the doc center.
For more details, the documentation can be found here.