Approvals
Changes that delete data or look like an older server are refused until you approve each one.
Why
A removed property is a dropped column
Removing an entity, a property or a generated key drops its table, column or sequence, and the data with it. A server with an older model would do the same. So the executor refuses, and the refusal names every approval the plan needs.
scala
import com.anjunar.hibernateddl.core.SchemaId
import com.anjunar.hibernateddl.executor.{Approval, ExecutionOptions}
ExecutionOptions(approvals = Set(
Approval.Drop(SchemaId("7f3a9c21/f34e45b6")), // a column, table or sequence
Approval.RenameBack(SchemaId("7f3a9c21")), // back to a name of an earlier revision
Approval.Revert(3) // a target equal to revision 3
))
Kinds
Four approvals
Each approval permits exactly one change. The same list can come from a Hibernate setting, comma-separated.
- Approval.Drop(id) · drop:<id>
- Drop the table, column or sequence with this ID, and its data.
- Approval.RenameBack(id) · rename-back:<id>
- Rename back to a name from an earlier revision.
- Approval.Revert(revision) · revert:<revision>
- Migrate to a target equal to that earlier revision.
- Approval.DropUniqueKey(signature) · drop-unique:<signature>
- Drop a unique key while its columns remain, so they may hold duplicates. Neither drop nor revert permits this.
properties
hibernate.ddl_manager.approvals=drop:7f3a9c21/f34e45b6,revert:3
Behaviour
Approvals permit, they never order
An approval whose change is not planned has no effect, so it can stay in place for a release.
Good to know
A dropped ID is retired; reusing it is refused even with approvals.
Drops run last and without CASCADE.
A view that depends on a dropped column makes the migration fail and roll back.
Remove the approval with the release after the drop.