Computational Logic Starting With 2026.1.0

Starting with ADITO 2026.1.0, row recalculation behavior is unified for the main access paths that process Entity rows. The UI, entities.getRows, and Entity Webservices use the same configurable preparation model when multiple records are processed one after another.

This change reduces differences between access paths and makes calculation behavior easier to validate. The behavior is controlled through the preference setting neonRowRecalculationMode.

info

From ADITO 2026.1.0 onward, jditoCalculationVersion uses V2 only. Projects that still depend on legacy calculation behavior must be reviewed during migration. Read the Blog article Saying Goodbye to Variable Graph V1 to learn more about this.

---

In a nutshell

• configurable calculation mechanism for processing several rows one after another in:
  • UI components – for example, a table
  • entities.getRows
  • Entity Webservice
• depends on the preference setting neonRowRecalculationMode:
  • LEGACY_RESET_FIELD_VALUES_ON_ROW_CHANGE: field values are reset before the next row is loaded. Slow; fresh calculation each time
  • REUSE_FIELD_VALUES_ON_ROW_CHANGE: no additional field reset is performed before the next row is loaded. Fast; needs to be kept in mind when customizing processes

Row Preparation During Multi-Row Processing

When several records are processed in sequence, ADITO internally prepares the row state before loading the next record.

Figure: Simplified model of repeated row preparation and processing during multi-row loading.

Configurating the behavior with neonRowRecalculationMode

The preference setting neonRowRecalculationMode defines how row data is prepared when ADITO iterates over multiple records.

This is relevant wherever rows are processed one after another:

• UI: tables, titledLists, card views and so on
• entities.getRows
• Entity Webservices (GET)

The setting is most important for Entities with calculated values/display values, deep variable dependencies and custom processes that read field values during row loading.

Available Modes

Mode	Behavior	Use this mode when
LEGACY_RESET_FIELD_VALUES_ON_ROW_CHANGE	Field values are reset before the next row is loaded. This provides a fresh calculation basis for each row. This is slow.	Existing custom logic depends on the previous legacy behavior or requires a full fresh start per row.
REUSE_FIELD_VALUES_ON_ROW_CHANGE	No additional field reset is performed before the next row is loaded. Recalculation relies on dependency-based updates between rows.	You want faster row processing and your custom logic is compatible with dependency-based recalculation.

LEGACY_RESET_FIELD_VALUES_ON_ROW_CHANGE is the compatibility mode. It is designed for projects where changing row calculation behavior would create functional risk.

REUSE_FIELD_VALUES_ON_ROW_CHANGE is the performance-oriented mode. It avoids the additional reset work between rows, but custom logic must not rely on a complete reset before each row.

Choosing a Mode

Use LEGACY_RESET_FIELD_VALUES_ON_ROW_CHANGE for legacy projects when behavior must remain similar. This is the safer option when existing custom logic has not yet been reviewed for row-state assumptions.

warning

Note that there are still changes in the behavior in versions prior to 2026.1.0 when using the LEGACY_RESET_FIELD_VALUES_ON_ROW_CHANGE setting.

When choosing this mode, the behavior of the UI pre-2026.1.0 becomes leading for entities.getRows and Entity Webservices (GET).

Use REUSE_FIELD_VALUES_ON_ROW_CHANGE for new projects and for performance-sensitive scenarios after validating the relevant custom processes and webservices. This mode is the preferred target for modern implementations because it avoids unnecessary recalculation work.

Expected Impact

The unified row recalculation model has three practical effects:

• UI loading, entities.getRows, and Entity Webservices behave consistently for row recalculation.
• Projects can choose between compatibility and performance with neonRowRecalculationMode.
• Customizing developers can migrate gradually by keeping legacy behavior while reviewing and adapting custom logic.

For context on the legacy behavior, see Computational Logic Before 2026.1.0.