ORDA – Say Hello to Aliases

Automatically translated from English

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
 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
 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!


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



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.

Roland Lannuzel

• Product Owner & 4D Expert •

After studying electronics, Roland went into industrial IT as a developer and consultant, building solutions for customers with a variety of databases and technologies. In the late 80’s he fell in love with 4D and has used it in writing business applications that include accounting, billing and email systems.

Eventually joining the company in 1997, Roland’s valuable contributions include designing specifications, testing tools, demos as well as training and speaking to the 4D community at many conferences. He continues to actively shape the future of 4D by defining new features and database development tools.