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
All properties get passed through a conversion step to convert them to types that can be passed to JDBC drivers.
Conversions happen in the newly introduced JdbcEnitityTemplate. It contains most of the code formerly found in the SimpleJdbcRepository.
Adds the @EnableJdbcRepositories annotation, which when used on a Spring configuration enables scanning packages for JDBC repositories.
Original pull request: #6.
Introduced interface for JdbcPersistentEntity to be consistent with other store implementations.
Introduced JdbcPersistentEntityInformation.getRequiredId(…) to return a value and throw an exception if it can't be obtained.
Added serialVersionUIDs to event implementations. Extracted Unset and SpecifiedIdentifier into top level classes to be able to reduce visibility. Introduced Specified interface and factory methods on Identifier to be able to create Identifier instances in all ways needed (specified / optional).
Extracted JdbcEvent interface from the previously thus named class to be able to let WithId and WithEntity extend that interface to avoid the cast in the default method of WithId. WithId now simply redeclares getId returning Specified so that the guarantees of returned object type simply adapt as soon as event types also implement that interface. Reduced the visibility of SimpleJdbcEvent as listeners could now just refer to JdbcEvent. Switched to a nullable field for the entity in SimpleJdbcEvent as ApplicationEvent already implies potential serializability and Optional is not Serializable.
Reorganized integration test setup to use configuration classes over FactoryBean implementations. Switched to AssertJ for test assertions.
Renamed UnableToSetIdException to UnableToSetId. A bit of Javadoc here and there. Formatting. No abbreviated variable names.
Original pull request: #5.
Different databases are now supported by means of Maven Profiles and Spring Profiles. There is one Profile for each supported database. The default Profile is equivalent to hql. There is a Maven Profile all-dbs, which runs the integration tests against all databases.
The databases need to be started outside the build. The build assumes the default configuration as I found it after `brew install <database>`
For now we support the databases mysql, postgres and hsqldb.
In order to make the new databases work setting of properties and reading generated ids was improved to do some simple conversions. This might be considered a first step towards DATAJDBC-104.
The project root contains some basic scripts for starting and stopping databases, as well as running a build against all supported databases. Integration tests using a database now use Rules instead of JUnit runners. This gives more flexibility when adding fancy stuff to the Tests in the form of other Rules.
Related issue: DATAJDBC-104.
Original pull request: #5.
Events now use the id as source. The id is encapsulated in a value object to support null ids in BeforeInsert events. Entity references in events are now Optionals. Dropped redundant Event suffix from events. Added "@since 2.0" to classes. Replaced constructors and getters with Lombok annotations. Simplified pom.xml. Extracted interface JdbcPersistentEntity and JdbcPersistentProperty. Integration tests use the Spring Test framework. Fixed test for entities with primitive id type.
Original pull request: #5.
The repository publishes events before and after inserting, updating and deleting entities, as well as after instantiation of entities. JdbcEvent ist the common super class of all events and makes the id and the entity available (if possible). Added issue id comments to tests from previous issues.
Original pull request: #5.
New instances get saved with an insert statement. Existing instances get updated. Also added some test to find certain corner cases that I feared may cause problems:
- ID properties being not editable (no setter and final).
- ID properties being primitive.
- ID properties not being named "id"
and fixed the issues resulting from those.
Original pull request: #5.
No longer using batch inserts, which won't (easily) hold up for long anyway, since we need to decide between update and insert anyway. If one wants to support batch insert one also has to check if any autoid columns are present, because those seem not to work with batch inserts with many or at least some drivers.
Related ticket: SPR-1836.
Original pull request: #5.
Creation of the necessary sql statements is now dynamic and driven in a trivial way by the entity.
Known issues with the solution that need to get fixed later:
- SQL generating code is in the repository and should go somewhere else.
- Mapping logic is very trivial and should go in a separate place.
Original pull request: #5.
Created a maven project based on Spring Data JPA. Created JdbcRepositoryFactory, which actually creates Repositories. Wired the construction of meta data. Implemented a dummy version of saving an entity to demonstrate availability of meta data. Included a simple test for exercising the JdbcRepositoryFactory and the resulting JdbcRepository.
Related pull request: #5.
