11.2. Read-only affect on property type
The following table summarizes how different property types are affected by making an entity read-only.
表 11.1. Affect of read-only entity on property types
Property/Association Type Changes flushed to DB? Simple(第 11.2.1 节 “Simple properties”)
no* Unidirectional one-to-one
Unidirectional many-to-one
(第 11.2.2.1 节 “Unidirectional one-to-one and many-to-one”)
no*
no*
Unidirectional one-to-many
Unidirectional many-to-many
(第 11.2.2.2 节 “Unidirectional one-to-many and many-to-many”)
yes
yes
Bidirectional one-to-one
(第 11.2.3.1 节 “Bidirectional one-to-one”)
only if the owning entity is not read-only* Bidirectional one-to-many/many-to-one
inverse collection
non-inverse collection
(第 11.2.3.2 节 “Bidirectional one-to-many/many-to-one”)
only added/removed entities that are not read-only*
yes
Bidirectional many-to-many
(第 11.2.3.3 节 “Bidirectional many-to-many”)
yes
* Behavior is different when the entity having the property/association is read-only, compared to when it is not read-only.
11.2.1. Simple properties
When a persistent object is read-only, Hibernate does not dirty-check simple properties.
Hibernate will not synchronize simple property state changes to the database. If you have automatic versioning, Hibernate will not increment the version if any simple properties change.
Session session = factory.openSession();
Transaction tx = session.beginTransaction();
// get a contract and make it read-only
Contract contract = ( Contract ) session.get( Contract.class, contractId );
session.setReadOnly( contract, true );
// contract.getCustomerName() is "Sherman"
contract.setCustomerName( "Yogi" );
tx.commit();
tx = session.beginTransaction();
contract = ( Contract ) session.get( Contract.class, contractId );
// contract.getCustomerName() is still "Sherman"
...
tx.commit();
session.close();
11.2.2. Unidirectional associations
11.2.2.1. Unidirectional one-to-one and many-to-one
Hibernate treats unidirectional one-to-one and many-to-one associations in the same way when the owning entity is read-only.
We use the term unidirectional single-ended association when referring to functionality that is common to unidirectional one-to-one and many-to-one associations.
Hibernate does not dirty-check unidirectional single-ended associations when the owning entity is read-only.
If you change a read-only entity's reference to a unidirectional single-ended association to null, or to refer to a different entity, that change will not be flushed to the database.
注意
If an entity is of an immutable class, then its references to unidirectional single-ended associations must be assigned when that entity is first created. Because the entity is automatically made read-only, these references can not be updated.
If automatic versioning is used, Hibernate will not increment the version due to local changes to unidirectional single-ended associations.
In the following examples, Contract has a unidirectional many-to-one association with Plan. Contract cascades save and update operations to the association.
The following shows that changing a read-only entity's many-to-one association reference to null has no effect on the entity's database representation.
// get a contract with an existing plan;
// make the contract read-only and set its plan to null
tx = session.beginTransaction();
Contract contract = ( Contract ) session.get( Contract.class, contractId );
session.setReadOnly( contract, true );
contract.setPlan( null );
tx.commit();
// get the same contract
tx = session.beginTransaction();
contract = ( Contract ) session.get( Contract.class, contractId );
// contract.getPlan() still refers to the original plan;
tx.commit();
session.close();
The following shows that, even though an update to a read-only entity's many-to-one association has no affect on the entity's database representation, flush still cascades the save-update operation to the locally changed association.
// get a contract with an existing plan;
// make the contract read-only and change to a new plan
tx = session.beginTransaction();
Contract contract = ( Contract ) session.get( Contract.class, contractId );
session.setReadOnly( contract, true );
Plan newPlan = new Plan( "new plan"
contract.setPlan( newPlan);
tx.commit();
// get the same contract
tx = session.beginTransaction();
contract = ( Contract ) session.get( Contract.class, contractId );
newPlan = ( Contract ) session.get( Plan.class, newPlan.getId() );
// contract.getPlan() still refers to the original plan;
// newPlan is non-null because it was persisted when
// the previous transaction was committed;
tx.commit();
session.close();
11.2.2.2. Unidirectional one-to-many and many-to-many
Hibernate treats unidirectional one-to-many and many-to-many associations owned by a read-only entity the same as when owned by an entity that is not read-only.
Hibernate dirty-checks unidirectional one-to-many and many-to-many associations;
The collection can contain entities that are read-only, as well as entities that are not read-only.
Entities can be added and removed from the collection; changes are flushed to the database.
If automatic versioning is used, Hibernate will update the version due to changes in the collection if they dirty the owning entity.
11.2.3. Bidirectional associations
11.2.3.1. Bidirectional one-to-one
If a read-only entity owns a bidirectional one-to-one association:
Hibernate does not dirty-check the association.
updates that change the association reference to null or to refer to a different entity will not be flushed to the database.
If automatic versioning is used, Hibernate will not increment the version due to local changes to the association.
注意
If an entity is of an immutable class, and it owns a bidirectional one-to-one association, then its reference must be assigned when that entity is first created. Because the entity is automatically made read-only, these references cannot be updated.
When the owner is not read-only, Hibernate treats an association with a read-only entity the same as when the association is with an entity that is not read-only.
11.2.3.2. Bidirectional one-to-many/many-to-one
A read-only entity has no impact on a bidirectional one-to-many/many-to-one association if:
the read-only entity is on the one-to-many side using an inverse collection;
the read-only entity is on the one-to-many side using a non-inverse collection;
the one-to-many side uses a non-inverse collection that contains the read-only entity
When the one-to-many side uses an inverse collection:
a read-only entity can only be added to the collection when it is created;
a read-only entity can only be removed from the collection by an orphan delete or by explicitly deleting the entity.
11.2.3.3. Bidirectional many-to-many
Hibernate treats bidirectional many-to-many associations owned by a read-only entity the same as when owned by an entity that is not read-only.
Hibernate dirty-checks bidirectional many-to-many associations.
The collection on either side of the association can contain entities that are read-only, as well as entities that are not read-only.
Entities are added and removed from both sides of the collection; changes are flushed to the database.
If automatic versioning is used, Hibernate will update the version due to changes in both sides of the collection if they dirty the entity owning the respective collections.