It is now ok for an entity to be “new” after saving.
We now only check that an entity is not new when the id is provided by the database.
If in such a case the entity is still “new” after saving it basically means obtaining the id from JDBC and setting it in the entity failed.
Removed need for entities in maps to have an id.
Together these changes simplify the requirements for Map values, which now can be value objects.
Instead of using Map.Entry we now use a dedicated class to hold key and value of a map entry.
This avoids side effects from the implementation of Map.Entry.
Replaced call to saveReferencedEntities with insertReferencedEntities which is simpler but equivalent since referenced entities always get only inserted, never updated.
Removed superfluous methods resulting from that change.
RowMapper can be configured either via the @Query(rowMapperClass = ….) or by registerign a RowMapperMap bean and register RowMapper per method return type.
@Bean
RowMapperMap rowMappers() {
return new ConfigurableRowMapperMap() //
.register(Person.class, new PersonRowMapper()) //
.register(Address.class, new AddressRowMapper());
}
When determining the RowMapper to use for a method the following steps are followed based on the return type of the method:
1. If the type is a simple type no RowMapper is used. Instead the query is expected to return a single row with a single column and a conversion to the return type is applied to that value.
2. The entity classes in the RowMapperMap are iterated until one is found that is a superclass or interface of the return type in question. The RowMapper registered for that class is used. Iterating happens in the order of registration, so make sure to register more general types after specific ones.
If applicable wrapper type like collections or Optional are unwrapped. So a return type of Optional<Person> will use the type Person in the steps above.
The ResultSetParameterValueProvider uses the relevant property for a requested parameter in order to obtain the proper column name to use.
Improved mocking of ResultSets in tests to actually fail when a non existing column gets requested instead of just returning null.
Extracted method to maintain a single level of abstraction.
Added description to assertion that wasn't obvious to me.
Added JavaDoc on existing method.
Commented repository methods in test with issue ids to ease understanding the purpose of each method.
Added @Modify for marking queries that perform DML or DDL.
Modifying queries with return type boolean or Boolean return wether the number of updated rows is greater 0.
This shouldn't be used for DML statements since it will always return false.
Original pull request: ##48.
In the past, Spring Data JDBC performed autoconfiguration such as gleaning whether or not MyBatis is on the classpath, and also whether or not certain other beans exist. This commit removes such flexible settings and instead wires up a JdbcMappingContext seeking an optional NamingStrategy and optional ConversionCustomizer. The other required beans will alert the end user if they don't exist.
All relevant test cases are updated to inject the proper components.
All autoconfiguration is being moved outside Spring Data JDBC, to eventually join Spring Boot after being shook out as an independent module.
Added a property path to DbActions in order to make them aware of the property it is related to.
Then used the JdbcPersistentProperty based on that get the name of the back-reference name of that property back to the root entity of that property.
This gets the NamingStrategy properly involved, as it should.
Instead of using the vanilla PropertyPath a new JdbcPropertyPath is introduced.
It allows for an empty path avoiding various null-checks.
Upgraded SD-Commons dependency to 2.1.x in order to utilise DATACMNS-1199.
Removed the now superfluous PropertyPaths and used PropertyPath methods instead.
Related issues:
DATACMNS-1204
DATACMSN-1199
If the id of an entity is provided as an additional parameter, i.e. the foreign key to an entity is the primary key, no id column is generated in the insert since it gets generated for the additional parameter.
Aggregate roots with properties of type java.util.Map get properly inserted, updated and deleted.
Known limitations:
- Naming strategy does not allow for multiple references via Set, Map or directly to the same entity.
- The table for the referenced Entity contains the column for the map key.
A workaround for that would be to manipulate the DbActions in the AggregateChange yourself.
The list of columns used in the SqlGenerator contained property names instead of column names, leading to errors when a non-trivial NamingStrategy was used.
If MyBatis-spring is available and a SqlSessionFactory in the Application Context we look for matching mapped sql statements instead of using the default generated SQL.
Introduced DataAccessStrategy as a new abstraction level, operating on a single entity. JdbcEntityOperations only contain operations related to complete Aggregates. Thereby also solving DATAJDBC-132.
Integration tests ending in HsqlIntegrationTest will only get executed using HsqlDb.
Related issue: DATAJDBC-132.
When loading the referenced entities get loaded by a separate select statement.
Changes to a collection get handled just like 1-1 relationships by deleting all and reinserting them again.
Introduced a separate method in JdbcPersistentProperty instead of just unsing the table name, although it currently still is the table name.
Now providing SqlTypes in SqlParameterSource, since MySql has a problem with null parameters when it doesn't know the type.
Fixed an error where a SQL-statement generated by the SqlGenerator was obviously wrong.
This change enables the manipulation of the DbChange instance before it gets interpreted and turned into SQL statements.
Only for Aggregate Roots events get fired, since these are the abstraction the repositories work on.
Insert and Update events got removed, since this distinction doesn't exist on the Aggregate Root level.
It only exists on the level of entities and/or tables which is represented by DbActions.
Improved some tests to properly check all the events triggered.
Created NamingStrategy and a default implementation that replicates the current solution. Several unit tests illustrates how to override the default and plugin a custom solution including a ThreadLocal, contextual one that could be user-based if, for example, Spring Security's SecurityContextHolder was used.
Fixed sql scripts for the various databases.
Postgres doesn't handle BigInts properly when just past to setObject. It needs special SqlType information.
Postgres can only handle BigInts up to Long.MAX_VALUE.
MySql stores dates only with seconds precision.
Code formatting. Removed few superfluous lines of code.
Renamed JdbcInterpreter to DefaultJdbcInterpreter.
The prefix Jdbc doesn't really carry much information in the SD JDBC project.
Renamed jdbcConverter fields to jdbcEntityWriter in order to match the type names.
Renamed DbChange to AggregateChange.
It isn't really about the database but about the aggregate.
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.
