Telerik OpenAccess Classic

Telerik OpenAccess ORM Send comments on this topic.
Persistent States
Programmer's Guide > OpenAccess ORM Classic (Old API) > Programming With OpenAccess > The OpenAccess ORM Object Lifecycle > Persistent States

Glossary Item Box

This documentation article is a legacy resource describing the functionality of the deprecated OpenAccess Classic only. The contemporary documentation of Telerik OpenAccess ORM is available here.

The following figure shows state changes for persistent class instances; i.e. object instances already present in the database:

Object State Changes—Existing Objects

Object State: hollow

When an object is retrieved from the database, it might initially be in the hollow state (You can find more information about hollow objects in Object Resolution).

Object State: persistent clean

Accessing a field of a hollow object for reading causes the object data to be loaded and the object is moved to the persistent clean state. When the transaction is terminated by either commit or rollback, the object is moved to the hollow state. In most cases, objects are generally retrieved from the database directly in the persistent clean state, and not in the hollow state, thus saving an extra step.

Object State: persistent dirty

If a persistent field of the persistent class is modified, the object is moved to the persistent dirty state. That is, the object is marked as having been modified. Modified objects are written to the database when you commit the transaction. Whether the transaction terminates with either commit or rollback, the object is moved to the hollow state.

Persistence capable class fields can also be specified as transient. Modifying a transient field does not mark the object as modified. Don't confuse transient fields with the transient state. Refer to Transient Attribute for more information about transient fields in persistence capable classes.

Object State: persistent deleted

If a hollow, persistent clean, or persistent dirty object is deleted (for example, with IObjectScope.Remove()), the object is moved to the persistent deleted state. During the transaction commit, the database object is deleted and the persistent deleted object instance in memory loses its object identity and its association with the object scope and is moved to the transient state. If the transaction is rolled back, the object instance reverts to the hollow state.

Object State Changes—Existing Objects

The following table shows the state changes that occur as an existing persistent class instance is manipulated:

Code

State Change

C# Copy Code
scope.Transaction.Begin();
VB .NET Copy Code
scope.Transaction.Begin()

 

C# Copy Code
Customer c1 = GetCustomer( . . . )
VB .NET Copy Code
Dim c1 As Customer = GetCustomer(...)

a Customer instance, c1, is retrieved from the database in the "hollow" state

C# Copy Code
Console.WriteLine( c1.Name );
VB .NET Copy Code
Console.WriteLine( c1.Name )

c1 is accessed (to read and print the name) and is moved to the "persistent clean" state

C# Copy Code
c1.Name = "Alex";
VB .NET Copy Code
c1.Name = "Alex"

a persistent field of c1 is modified and the object state is moved to the "persistent dirty" state

C# Copy Code
Customer c2 = GetCustomer( . . . );
VB .NET Copy Code
Dim c2 As Customer = GetCustomer(...)

c2 is retrieved in the "hollow" state

C# Copy Code
scope.Remove( c2 );
VB .NET Copy Code
scope.Remove( c2 )

c2 is moved to the "persistent deleted" state

C# Copy Code
scope.Transaction.Commit();
VB .NET Copy Code
scope.Transaction.Commit()

c1 is stored and moved to the "hollow" state. c2 is not stored and moved to the "transient" state