Entity view for partial updates

[beikov]

We could add some more annotations for entity views and extend the entity view manager to allow partial updates to the entities they map to.
Need support for version fields too. Note that for now, only updates are considered.

[beikov]

POC implemented by 27417ef

[beikov]

Works for simple attributes, but collection updates and cascading updates aren't implemented yet.

[beikov]

Also there is no support for subviews yet

[beikov]

Updatable entity views

Updating should be adaptive by default. If we can avoid loading the entity, we use an update query.
This requires that the entity has no changes in owned collections, but only basic attributes or inverse collections.

If collections are affected, we must load the entity and replay collection changes.
Non-owned collections are udated from the owning side.
If only non-owned collections are affected, only a version update of the entity is done through a query.

The originally planned features are

• Possibility to only allow updating specific fields => provide setter for that field
• State tracking to enable partial updating instead of full updates => flag in updateable annotation
• Support version field and optimistic locking
• Support for updating *ToMany relations and element collections
• Support updateable subviews
• Support cascading updates of relations or subviews
• Support setters that are protected/default which are called by user methods
• Support access to modified state
• Support entities that use field access strategy
• Support configuration of flush strategy
• Support mapping entity ids instead of entity types for all relation types
• Integration with constraint violation exception mapping
• Dynamically generated delegating proxy classes for entities or other entity views to use case specific entity view interfaces

Version field support

This is a bit tricky as it requires special attention when doing collection updates on partial enabled entity views. Normally updates of basic and *ToOne fields would be done with an update query, but when collection updates are also involved, we have to take special care regarding the version update.

*ToMany and element collection support

Since *ToMany and element collection updates can only be implemented with JPA by changing a persistent entity, we will implement these modifications similar to the following example

SomeEntity e = em.getReference(SomeEntity.class, id)
e.getElementCollection().add(...)

To efficiently implement collection semantics, one would have to track changes done to a collection. Since the JPA provider does that already, I am thinking of a lightweight tracking mechanism. The best that I have been able to come up with was tracking method calls to the collection and replaying them on the collection of the entity.

Updateable subviews

Supporting updateable subviews requires some change to the change recognition as we have to go into the subview and check for changes there too. This shouldn't be a big deal, but then again, the version field semantics have to be tested.

Cascading updates of relations and subviews

Subviews can be supported automatically as we are tracking changes to them, but when having *ToOne relations mapped in the entity view, it's not so easy.
We need some kind of mechanism to check if an entity is dirty so we can merge it. Note that we can also have updateable relations in subviews!

Setters with modifier protected/default for use in user methods

A user might want to declare public action methods which mutate the state by calling setters in a more domain driven way. Since the setters would not have to be exposed to be able to call them within such a action method, we should allow to use the modifiers protected/default for setters.

Access to modified state

Another feature that will differentiate updatable entity views from entities is the support for getting access to the changed state. It should be at least possible to query the metamodel attributes of an instance that changed. Getting access to the original state or the current DB state vs. the state of the updatable entity view might also be considered.

Field access strategy

Entities that use the field access strategy should also be supported. Currently the flushing of values to an entity instance only work when getters/setters are available. It should also be possible to use entity types that use the field access strategy. Make sure this works with bytecode enhanced entities.

Configuration of flush strategy

It might be desirable to always use the entity reference flush strategy so allow this behavior to be fine tuned.

Entity Id mapping for all relation types

Instead of requiring to map the entity types or subview types, it might be desireable to be able to map the id of the target type instead.

Constraint violation exception mapping integration

Integrate support for constraint violation exception mapping via #170 to enrich the exceptions with entity view related information. Maybe we can even provide a declarative way for exception mapping?

Dynamically generated delegating proxy classes

Apart from our very efficient proxy classes, we also have to generate proxy classes that do delegation to instances of a compatible type. In case of updateable entity views, the delegating proxy class also has to implement the UpdateableProxy class properly.

It should be possible to create an entity view A by

• Entity that is an instance of the entity for which the entity view A is => This requires a JPQL expression interpreter(Note: we should interpret lazily)
• Entity view that is a subtype of entity view A => Simple delegation
• Entity id => will use em.getReference

[beikov]

Moving this to 1.2.0 because the scope has been broadened too much already.

[beikov]

Moving to 1.4.0 as the experimental version is already done.

[beikov]

Closing as most of the thing are done. I created issues for the other stuff.