25 lines
1.8 KiB
Plaintext
25 lines
1.8 KiB
Plaintext
== Spring Data JDBC How To ID Generation
|
|
|
|
There are multiple ways how the generation of IDs can be controlled.
|
|
|
|
1. The default is to let the database create the ID by using a `AUTOINCREMENT`, `SERIAL` or `IDENTITY` column.
|
|
If you try to save a new aggregate root with a preset ID you will receive an exception.
|
|
See `IdGenerationApplicationTest.cantSaveNewAggregateWithPresetId`.
|
|
|
|
The reason is that Spring Data JDBC will inspect the aggregate root, notes that the ID is not `null` and tries to perform an update which will update 0 rows and cause an exception.
|
|
|
|
2. You can manually set the id of an aggregate root to a value of your choice if you use `JdbcAggregateTemplate.insert`.
|
|
This bypasses the check if an update or insert is to be performed and always performs an insert.
|
|
See `IdGenerationApplicationTest.insertNewAggregateWithPresetIdUsingTemplate`.
|
|
|
|
3. You may use a `BeforeSaveEntityCallBack` to set the id of aggregate roots with null ID.
|
|
This has the benefit of being transparent in to your domain code, as it should be since IDs are normally not relevant to it.
|
|
See `IdGenerationApplicationTest.idByCallBack` and `IdGenerationApplication.beforeSaveCallback`.
|
|
As long as your entity is mutable you might as well use an `BeforeSaveEntityListener`, but since the callback works for both cases it is the recommended approach.
|
|
|
|
4. If you add a version attribute, i.e. one annotated with `@Version` that attribute is used to determine if the aggregate is new or not, leaving you free to set the ID as you see fit.
|
|
See `IdGenerationApplicationTest.determineIsNewPerVersion`.
|
|
|
|
5. The final option is to let your aggregate root implement `Persistable` which allows you to define your own `isNew` method, which controls if we perform an insert or an update.
|
|
See `IdGenerationApplicationTest.determineIsNewPerPersistable`.
|