Skip to main content

At the Dawn of a New Era: EntityModel × Calculations

· 3 min read
Johannes Goderbauer
Johannes Goderbauer
Tech-Lead Neon Backend @ ADITO Platform

New Era

The ADITO UnifiedEntityModel is about to take a major step forward.

With neonRowRecalculationMode, the way EntityModels look at process dependencies, calculations, and a perspective beyond row-level dependencies is changing fundamentally. Instead of treating recalculation as one familiar chain of work, the new approach opens the door to a much smarter view of what really needs to happen, when it needs to happen.

The result is expected to have a major positive impact on performance. At the same time, this is not the finish line yet. It is an active development step, a clear move in the right direction, and the foundation for improvements that will continue to grow from here.

What is changing?​

The big shift is simple, but powerful: the EntityModel is moving away from recalculating the whole row again and again.

Until now, the familiar approach was: a row changes, and every calculated part of that row is recalculated from scratch. That is predictable in one way, but it also means that the same data can be recalculated multiple times even when nothing relevant has changed.

The new approach is much more efficient:

  • Before: every row is recalculated completely
  • After: only changed fields are recalculated, and the same data is not recalculated multiple times

Why does this matter? Performance.

Especially in EntityModels with many calculated values, display values, deep dependencies, or complex processes, avoiding unnecessary recalculation for multiple rows can make a real difference.

Try it with 2026.1.0​

As of ADITO 2026.1.0, this new direction can be tried out with the neonRowRecalculationMode property set to REUSE_FIELD_VALUES_ON_ROW_CHANGE.

We recommend trying this first in a dedicated evaluation system, such as a development, test, or QA environment. Depending on the existing EntityModel logic, enabling the new mode may require manual upgrade steps, so it is worth validating the behavior before rolling it out more broadly. The upgrade guide contains the details for that approach.

For comparison, the available modes are:

  • LEGACY_RESET_FIELD_VALUES_ON_ROW_CHANGE: field values are reset before the next row is loaded. This keeps behavior close to the previous UI behavior, but it requires additional recalculation work.
  • REUSE_FIELD_VALUES_ON_ROW_CHANGE: field values are reused between row changes, and recalculation relies on dependency-based updates instead of a complete reset for every row.

This is the first visible step into a more performance-oriented calculation model, not the final form of that model. It also gives us a stronger foundation for future improvements, because the EntityModel can now reason much more precisely about what really changed and what can safely stay as it is.

More consistent, more predictable​

There is another important part of this change: the system is now much more consistent and predictable, even in the legacy mode.

The UI, entities.getRows, and Entity Webservices now follow the same configurable row recalculation model when multiple rows are processed one after another. That means fewer surprises between access paths and a clearer model for validating custom logic.

This is not the end of the story. The goal has not been fully reached yet, and there is still a lot of potential for further improvement. But the first important step is here, and it already changes the direction of process calculations in the UnifiedEntityModel.

For a technical deep dive, see Computational Logic Starting With 2026.1.0.

./Johannes

Update note​

Edited on 2026-06-01 to clarify the active-development status and set expectations for future improvements.