fec4f99257
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
Spring Data JDBC
The primary goal of the Spring Data project is to make it easier to build Spring-powered applications that use data access technologies. This module deals with enhanced support for JDBC based data access layers.
Features
Getting Help
Quick Start
Execute Tests
Fast running tests
Fast running tests can executed with a simple
mvn test
This will execute unit tests and integration tests using an in-memory database.
Running tests with a real database
To run the integration tests against a specific database you nned to have the database running on your local machine and then execute.
mvn test -Dspring.profiles.active=<databasetype>
This will also execute the unit tests.
Currently the following databasetypes are available:
- hsql (default, does not need to be running)
- mysql
Run tests with all databases
mvn test -Pall-dbs
This will execute the unit tests, and all the integration tests with all the databases we currently support for testing. The databases must be running.
Contributing to Spring Data JDBC
Here are some ways for you to get involved in the community:
- Get involved with the Spring community by helping out on stackoverflow by responding to questions and joining the debate.
- Create JIRA tickets for bugs and new features and comment and vote on the ones that you are interested in.
- Github is for social coding: if you want to write code, we encourage contributions through pull requests from forks of this repository. If you want to contribute code this way, please reference a JIRA ticket as well covering the specific issue you are addressing.
- Watch for upcoming articles on Spring by subscribing to spring.io.
Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributor’s agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. If you forget to do so, you'll be reminded when you submit a pull request. Active contributors might be asked to join the core team, and given the ability to merge pull requests.