From v4.2, cascade merging is no longer configurable (and is kept enabled for all relations).
This section is about application level cascading. For that to work, we need to have relations populated.
When persisting or removing entity, all your references are by default cascade persisted. This means that by persisting any entity, ORM will automatically persist all of its associations.
You can control this behaviour via
cascade attribute of
New entities without primary key will be always persisted, regardless of
Here is example of how cascade persist works:
When cascade persisting collections, keep in mind only fully initialized collections will be cascade persisted.
Cascade remove works same way as cascade persist, just for removing entities. Following
example assumes that
Book.publisher is set to
Note that cascade remove for collections can be inefficient as it will fire 1 query for each entity in collection.
Keep in mind that cascade remove can be dangerous when used on
as cascade removed entity can stay referenced in another entities that were not removed.
In addition to
Cascade.REMOVE, there is also additional and more aggressive remove
cascading mode which can be specified using the
orphanRemoval flag of the
orphanRemovalflag behaves just like
Cascade.REMOVEfor remove operation, so specifying both is redundant.
Cascade.REMOVE, you would need to remove the
Author entity to cascade
the operation down to all loaded
Books. By enabling orphan removal on the collection,
Books will be also removed when they get disconnected from the collection (either via
remove(), or by replacing collection items via
In this example, no
Book would be removed with simple
Cascade.REMOVE as no remove operation
This is only supported in SQL drivers.
As opposed to the application level cascading controlled by the
cascade option, we can
also define database level referential integrity actions:
on update and
Their values are automatically inferred from the
cascade option value. You can also
control the value manually via