Persistent entities: improved processing of plain transient properties upon save

Description

There are situations where persistent entities need to include plain transient properties as part of their structural schema. At the moment such properties need to have their meta-state reset before a corresponding entity instance can be persisted. This happens due to the fact that the persistence logic does not differentiate between persistent and non-persistent properties.

If the meta-state is not reset, non-persistent properties are recognised as dirty and get included as part of the db update, which eventually fails. The same does not happen during persistence of new entity instances due to saving through a Hibernate session, which ignores non-persistent (and therefore non-mapped from the Hibernate perspective) properties.

It is proposed to enhance the persistence logic in order to simplify coding at the level of applications.

Change proposal

[x] 0. Modify PersistentEntitySaver.saveModifiedEntity to skip all non-persistent properties from the database update. This is the core required change.

Once the above change is implemented, the default behaviour of re-retrieval of saved entities, which happens upon successful saving (subject to argument maybeFetch), would result in all those non-persistent properties "losing" their value (i.e., they would be null). In other words, the input instance for saving had some values in non-persistent properties, but the output instance would have no values for the same properties.

Such behaviour may not necessarily be the most convenient from the development perspective. For example, if an entity modified by a user via a corresponding Entity Master, where non-persistent properties are displayed and can have their values changed, that user may expect to observe the same values for non-persistent properties after saving changes (as opposed to observing empty values). However, this only applies to plain properties (but not to calculated or crit-only properties).

We need to consider 2 options and choose 1 for implementation:

~1. Leave non-persistent properties empty (i.e., null) after save. No actual changes would need to be implemented for this options. The end-application engineer would need to take care of re-assigning values to such properties after save, if deemed appropriate.~

[x] 2. Maintain the values for plain properties after save, with meta-state reset (i.e., those properties would not be considered dirty).

It would be required to synchronise the behaviour of saving new and existing instances with respect to processing plain properties after save.

Expected outcome

A well defined and deterministic behaviour of using non-persistent properties as part of persistent entities.

fieldenms / tg