java.lang.Object | |
↳ | org.hibernate.collection.AbstractPersistentCollection |
Known Direct Subclasses |
Known Indirect Subclasses |
Base class implementing PersistentCollection
Nested Classes | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
AbstractPersistentCollection.DelayedOperation |
Fields | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
UNKNOWN |
Public Constructors | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Not called by Hibernate, but used by non-JDK serialization,
eg.
|
Protected Constructors | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Public Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Called after initializing from cache
| |||||||||||
Called after inserting a row, to fetch the natively generated id
| |||||||||||
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
| |||||||||||
Is the initialized collection empty?
| |||||||||||
Called after reading all rows from the JDBC result set
| |||||||||||
To be called internally by the session, forcing
immediate initialization.
| |||||||||||
Get the index of the given collection entry
| |||||||||||
Get the current collection key value
| |||||||||||
get all "orphaned" elements
| |||||||||||
Get the owning entity.
| |||||||||||
Iterate the "queued" additions
| |||||||||||
Get the current role name
| |||||||||||
Get the current session
| |||||||||||
Get the snapshot cached by the collection
instance
| |||||||||||
return the user-visible collection (or array) instance
| |||||||||||
Does this instance have any "queued" additions?
| |||||||||||
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?
| |||||||||||
Do we need to completely recreate this collection when it changes?
| |||||||||||
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
| |||||||||||
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?
|
Protected Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Given a collection of entity instances that used to
belong to the collection, and a collection of instances
that currently belong, return a collection of orphans
| |||||||||||
Get the current snapshot from the session
| |||||||||||
Initialize the collection, if possible, wrapping any exceptions
in a runtime exception
| |||||||||||
Is this collection in a state that would allow us to
"queue" clear? This is a special case, because of orphan
delete.
| |||||||||||
Is this collection in a state that would allow us to
"queue" operations?
| |||||||||||
Is this collection in a state that would allow us to
"queue" puts? This is a special case, because of orphan
delete.
| |||||||||||
After reading all existing elements from the database,
add the queued elements to the underlying collection.
| |||||||||||
Queue an addition
| |||||||||||
Called by any read-only method of the collection interface
| |||||||||||
Called by the size() method
| |||||||||||
Called by any writer method of the collection interface
|
[Expand]
Inherited Methods | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
From class
java.lang.Object
| |||||||||||
From interface
org.hibernate.collection.PersistentCollection
|
Not called by Hibernate, but used by non-JDK serialization, eg. SOAP libraries.
Called after initializing from cache
Called after inserting a row, to fetch the natively generated id
HibernateException |
---|
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
Is the initialized collection empty?
Called after reading all rows from the JDBC result set
To be called internally by the session, forcing immediate initialization.
HibernateException |
---|
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.
Does this instance have any "queued" additions?
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?
Do we need to completely recreate this collection when it changes?
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 |
---|
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?
Given a collection of entity instances that used to belong to the collection, and a collection of instances that currently belong, return a collection of orphans
HibernateException |
---|
Initialize the collection, if possible, wrapping any exceptions in a runtime exception
writing | currently obsolete |
---|
LazyInitializationException | if we cannot initialize |
---|
Is this collection in a state that would allow us to "queue" clear? This is a special case, because of orphan delete.
Is this collection in a state that would allow us to "queue" operations?
Is this collection in a state that would allow us to "queue" puts? This is a special case, because of orphan delete.
After reading all existing elements from the database, add the queued elements to the underlying collection.
Called by any read-only method of the collection interface
Called by the size() method
Called by any writer method of the collection interface