org.hibernate.collection.PersistentCollection |
Known Indirect Subclasses |
Persistent collections are treated as value objects by Hibernate.
ie. they have no independent existence beyond the object holding
a reference to them. Unlike instances of entity classes, they are
automatically deleted when unreferenced and automatically become
persistent when held by a persistent object. Collections can be
passed between different objects (change "roles") and this might
cause their elements to move from one database table to another.
Hibernate "wraps" a java collection in an instance of
PersistentCollection. This mechanism is designed to support
tracking of changes to the collection's persistent state and
lazy instantiation of collection elements. The downside is that
only certain abstract collection types are supported and any
extra semantics are lost
Applications should never use classes in this package
directly, unless extending the "framework" here.
Changes to structure of the collection are recorded by the
collection calling back to the session. Changes to mutable
elements (ie. composite elements) are discovered by cloning their
state when the collection is initialized and comparing at flush
time.
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Called after initializing from cache
| |||||||||||
Called after inserting a row, to fetch the natively generated id
| |||||||||||
Called before any elements are read into the collection,
allowing appropriate initializations to occur.
| |||||||||||
Called just before reading any rows from the JDBC result set
| |||||||||||
Clear the dirty flag, after flushing changes
to the database.
| |||||||||||
Mark the collection as dirty
| |||||||||||
Disassemble the collection, ready for the cache
| |||||||||||
Is the collection empty? (don't try to initialize the collection)
| |||||||||||
Called after reading all rows from the JDBC result set
| |||||||||||
Iterate all collection entries, during update of the database
| |||||||||||
Does an element exist at this entry in the collection?
| |||||||||||
Does the current state exactly match the snapshot?
| |||||||||||
To be called internally by the session, forcing
immediate initialization.
| |||||||||||
Get all the elements that need deleting
| |||||||||||
Get the value of the given collection entry
| |||||||||||
Get the index of the given collection entry
| |||||||||||
Get the index of the given collection entry
| |||||||||||
Get the current collection key value
| |||||||||||
get all "orphaned" elements
| |||||||||||
Get the owning entity.
| |||||||||||
Get the "queued" orphans
| |||||||||||
Get the current role name
| |||||||||||
Return a new snapshot of the current state of the collection
| |||||||||||
Get the snapshot value of the given collection entry
| |||||||||||
Get the snapshot cached by the collection
instance
| |||||||||||
return the user-visible collection (or array) instance
| |||||||||||
Does this instance have any "queued" additions?
| |||||||||||
Read the state of the collection from a disassembled cached value
| |||||||||||
Could the application possibly have a direct reference to
the underlying collection implementation?
| |||||||||||
Is the collection dirty? Note that this is only
reliable during the flush cycle, after the
collection elements are dirty checked against
the snapshot.
| |||||||||||
Is the snapshot empty?
| |||||||||||
Is the collection unreferenced?
| |||||||||||
Is this the wrapper for the given underlying collection instance?
| |||||||||||
Do we need to insert this element?
| |||||||||||
Do we need to completely recreate this collection when it changes?
| |||||||||||
Do we need to update this element?
| |||||||||||
After flushing, clear any "queued" additions, since the
database state is now synchronized with the memory state.
| |||||||||||
Called before inserting rows, to ensure that any surrogate keys
are fully generated
| |||||||||||
Iterate the "queued" additions
| |||||||||||
Read a row from the JDBC result set
| |||||||||||
Associate the collection with the given session.
| |||||||||||
Set the reference to the owning entity
| |||||||||||
After flushing, re-init snapshot state.
| |||||||||||
Disassociate this collection from the given session.
| |||||||||||
Is this instance initialized?
|
Called after initializing from cache
Called after inserting a row, to fetch the natively generated id
HibernateException |
---|
Called before any elements are read into the collection, allowing appropriate initializations to occur.
persister | The underlying collection persister. |
---|---|
anticipatedSize | The anticipated size of the collection after initilization is complete. |
Called just before reading any rows from the JDBC result set
Clear the dirty flag, after flushing changes to the database.
Mark the collection as dirty
Disassemble the collection, ready for the cache
HibernateException |
---|
Is the collection empty? (don't try to initialize the collection)
Called after reading all rows from the JDBC result set
Iterate all collection entries, during update of the database
Does an element exist at this entry in the collection?
Does the current state exactly match the snapshot?
HibernateException |
---|
To be called internally by the session, forcing immediate initialization.
HibernateException |
---|
Get all the elements that need deleting
HibernateException |
---|
Get the index of the given collection entry
Get the index of the given collection entry
persister | it was more elegant before we added this... |
---|
get all "orphaned" elements
HibernateException |
---|
Get the owning entity. Note that the owner is only set during the flush cycle, and when a new collection wrapper is created while loading an entity.
Return a new snapshot of the current state of the collection
HibernateException |
---|
Get the snapshot value of the given collection entry
Get the snapshot cached by the collection instance
Does this instance have any "queued" additions?
Read the state of the collection from a disassembled cached value
HibernateException |
---|
Could the application possibly have a direct reference to the underlying collection implementation?
Is the collection dirty? Note that this is only reliable during the flush cycle, after the collection elements are dirty checked against the snapshot.
Is the collection unreferenced?
Is this the wrapper for the given underlying collection instance?
Do we need to insert this element?
HibernateException |
---|
Do we need to completely recreate this collection when it changes?
Do we need to update this element?
HibernateException |
---|
After flushing, clear any "queued" additions, since the database state is now synchronized with the memory state.
Called before inserting rows, to ensure that any surrogate keys are fully generated
HibernateException |
---|
Read a row from the JDBC result set
HibernateException | |
---|---|
SQLException |
Associate the collection with the given session.
HibernateException | if the collection was already associated with another open session |
---|
After flushing, re-init snapshot state.
Disassociate this collection from the given session.
Is this instance initialized?