Alternative to static entities - Enums
359
Views
5
Comments
New
Backend

We've seen a lot of discussion around Static Entities lately, for example, this idea

While Static Entities provide some value for enumeration use cases, they fall short in a lot of ways:

  • They are stored in the database.
  • They are expensive compute wise (more than they should be) to retrieve.
  • They cost AOs.
  • To use them on client side (other than the ID), they need to be manually synced.
  • Developers need to understand the aforementioned details to use them correctly.

Traditional Enums in high code languages are much better. They are directly in the code, making them available at no cost to the caller. 

Since OutSystems is a giant compiler, Enums should be a first-class construct that:

  • Are compiled into constants rather than stored in the database.
  • Are accessible both server-side and client-side without requiring manual synchronization.
  • Do not consume AOs.
  • Can be used in Service Studio like a variable.
  • Maintain type safety like a Static Entity ID.

Static Entities are an old primitive of the platform. I don't believe changing them at this stage is a good move, so I propose creating a new primitive—Enums—that align with modern best practices while keeping the low-code philosophy.

Actually a static entity in OutSystems is a table in the database AND an enumeration already.

I don't think anything should change in the language, which would just cause a lot of refactoring to save AO's.

We should all stay united and make a point that a 1AO for 1 Static entity is too expensive, either static entities are not costing an AO, or we reach a middle ground, where for example 20 static entities cost 1 AO. The benefit of this solution, that all our code remains to work, and OutSystems doesn't have to change the product. All they need to do is change the license structure.

@Daniël Kuhlmann yes I agree with you in the licensing issue, I should have made that clear.

Regarding the static entity functionality, while the statement "static entity in OutSystems is a table in the database AND an enumeration already" is technically true, I do feel like it's missing the full potential of traditional Enums. Enums are code, not a database table. They should be available everywhere without having to query the database or syncing them to client side.

The idea of introducing a new primitive is exactly that our current code continues to work as is, but a more modern and powerful option is added for new projects.

As I wrote the static entity is a database table AND an enumeration. 

I don't understand why you always need to query the database? Why? Yes when you use the static entity in an aggregate, but not for conditions you just write staticentity.record in your expression, no need to query the database. Basically, you use the enumeration.



The enumeration is only available for IDs. There's a lot of use cases where you want more. For example:

  • You want a client side dropdown to show all options in the static entity - you have to fetch it
  • You want to access a field other than the ID - you have to fetch it

I'm currently building a mobile application that has some local first behavior and syncing these entities manually is a lot of work. It makes developers think of syncing, local storage, invalidation, etc.

Agree with @Tiago Ribeiro

Besides the AO cost, there are some other problems with static entities, such as needing to fetch them to make use of the attributes on client side.  

And at first glance, it gets worse in ODC because of application <-> library differences.

Dorine