Cascade and session operations

Each cascade setting of hibernate corresponds to a session method.When you call this method to process an object, if the object has an associated object configured with this method for Cascade, the associated object will be processed in the same way!

The following cascade settings are provided in total:

Package org. hibernate. Annotations;

/**
* Cascade types (can override default ejb3 Cascades
*/
Public Enum cascadetype {
All,
Persist,Persist operations
Merge,Merge operations
Remove,Corresponding remove operation
Refresh,Corresponding refresh operation
Delete,Corresponding delete operation
Save_update,Corresponding save, update, saveorupdate operations
Replicate,Corresponding replicate operation
Delete_orphan,
Lock,Corresponding Lock Operation
Evict,Corresponding evict operation
}

 

You should be familiar with the last six types of interfaces. They are all cascade options corresponding to some interfaces in the early sessions.

The four green functions are actually no different, but they are the four interfaces supported by JPA specifications. I think one of the main reasons why hibernate sessions introduce these four interfaces is that when we use JPA standard annotations to prepare cascading, these four cascade options are available, if you want some cascade settings to take effect, the session must provide the corresponding method!

 

For example:

Public class item {
...
@ Onetoetype (cascade = {cascadetype. persist,
Cascadetype. merge,
Cascadetype. Remove },
Mappedby = "item ")
Private set <bid> bids = new hashset <bid> ();
...
}

At this time, if we call session. persist (item), all bids in its bids set will also be together with persist.

However, if you use session. Save, no.

In general, cascade-to-one and sequence-to-sequence do not use cascade operations very well. One-to-one and one-to-one are the most common cascade operations!

A

A

A

A