Updatable entity view prototype

[beikov]

We have an extensive feature list provided in #127 and we should prototype some of the features so we can test them in real applications. It is not a goal to implement all features in this release but get a minimal version that can be used and actually makes sense. We should focus on the features rather than the best implementation or various strategies to see if this model is actually usable in real applications or how it should be adapted.

[beikov]

During the discussion with some of my fellow colleagues, we thought through some questions that came to my mind.

Should we support only managed i.e. created via factory, or also instances of custom subtypes

At first, only allow managed instances, in a final version we might also allow custom subtypes for easier integration

Do we want a special designation of create models i.e. models that are used for creating entities?

Yes we want that(@CreatableEntityView) and also the "completeness" validation that can be done because of the special designation. It should be possible to disable validation for certain attributes that might be set in listeners. Updatable views should also be usable to create new instances, although this behavior should be configurable.

Where should generated ids be set?

Set the value on the respective objects. Note that this requires such views to have an id mapping just like updatable entity views, although it doesn't have to be updatable.

How should cascading and subtypes be handled when having updatable/non-updatable mutable types?

We decided on the defaults

• Allowed subtypes must be declared. If a not allowed subtype is encountered, an exception is thrown.
• Updatable mappings will only cascade UPDATE by default, when the static type is an updatable view.
• Updatable mappings will only cascade PERSIST by default, when the static type is a creatable view.
• Mutable mappings will cascade UPDATE by default.
• Non-Updatable collection mappings of non-mutable types will not cascade anything by default.
• Non-Updatable collection mappings of mutable types will cascade UPDATE by default.
• Non-Updatable mappings will never change the entity relation representing it i.e. no "collection add".

What update and flush strategies should be supported?

Currently we have the partial strategy, which does dirty checking and skips updates of non-dirty attributes and the full strategy, which always updates everything.
The full strategy has a better query cache hit ratio, but might involve higher data transfer.
The partial strategy has better data transfer characteristics, but is a bit more complicated to compute and has a bad query cache hit ratio.
We decided that although both strategies have valid use cases, we'd like a hybrid of the two strategies as new default. The default strategy should still be configurable on the @UpdatableEntityView annotation.

The new strategy will do dirty checking like the partial strategy and will do a full update of the object, if at least one attribute is dirty. By doing the dirty checking, the strategy can implement entity graph loading or query flushing more efficiently.

What should the "updateFull" method do when subviews have partial updating configured?

Should ignore the configured default and do full updates all the way.

Bi-Directional mapping optimizations

When mapping a collection in an entity view that has a inverse relation mapping, the "collection add/remove" operations can be implemented by updating the inverse relations respectively. This is a nice optimization that should be implemented at some point.

Do we really need access to dirty state?

After discussing possible use cases like auditing or conditional checks, we decided that this is a very important feature. Maybe we could even annotate a lock level or so that should be used when a change is detected.

Other features we discussed

• Listeners for "pre-load", "pre-persist" and "pre-update" events
• Entity views without a root i.e. aggregates of multiple roots