Aggregate roots that reference other entities get correctly stored, updated and loaded.
In order to keep this a simple as possible, referenced entities get deleted and recreated on each update.
While this is inefficient it gets the job done and makes sense if we assume referenced entities are owned by that aggregate root.
References to other aggregate root could be implemented by using just the id. With the event mechanism one could even inject repositories into the entities, so they could provide getters to the actual referenced aggregate root.
The process of storing an entity now works as follows:
The request to store an entity is converted into a DbChange object containing a list of DbActions. Each DbAction represents a single change made to the data base, I.e. an insert, update or delete statement.
This DbChange then gets interpreted by the interpreter to actually create sql statements and execute them.
This should allow various customizations in the future and for users:
- We could read the DbActions from the aggregate root itself, if it implements a given interface
- A user can modify the way DbActions get created for a requested change. Either by replacing the Jdbc[Delete]EntityWriter that performs this conversion or by modifying the DbChange in an event handler.
- By changing the interpreter actually performing the actions one could change completely the sql used for the actions.
Since we currently only do one-to-one relationships selects are simply joins.
In order to encapsulate the construction of select statements from entities the SelectBuilder got introduced.
Also SqlGenerators and the generated sql is properly cached, if it does not depend on additional information.
This commit also contains necessary changes due to DATACMNS-1101.
Related issues:
DATACMNS-1101
DATAJDBC-115
fec4f99257