EOCooperatingObjectStore

Inherits from:
EOObjectStore

Implements:
NSLocking

Package:
com.webobjects.eocontrol

Class Description

EOCooperatingObjectStore is a part of the control layer's object storage abstraction. It is an abstract class that defines the basic API for object stores that work together to manage data from several distinct data repositories.

For more general information on the object storage abstraction, see "Object Storage Abstraction" (page 23) in the introduction to the EOControl Framework.

The interaction between EOCooperatingObjectStores is managed by another class, EOObjectStoreCoordinator. The EOObjectStoreCoordinator communicates changes to its EOCooperatingObjectStores by passing them an EOEditingContext. Each cooperating store examines the modified objects in the editing context and determines if it's responsible for handling the changes. When a cooperating store has changes that need to be handled by another store, it communicates the changes to the other store back through the coordinator.

For relational databases, Enterprise Objects Framework provides a concrete subclass of EOCooperatingObjectStore, EODatabaseContext (EOAccess). A database context represents a single connection to a database server, fetching and saving objects on behalf of one or more editing contexts. However, a database context and an editing context don't interact with each other directly-a coordinator acts as a mediator between them.

Interfaces Implemented

NSLocking
lock
unlock

Method Types

Committing or discarding changes
commitChanges
ownsGlobalID
rollbackChanges
prepareForSaveWithCoordinator
recordChangesInEditingContext
recordUpdateForObject
Returning information about objects
valuesForKeys
Determining if the EOCooperatingObjectStore is responsible for an operation
ownsObject
ownsGlobalID
handlesFetchSpecification

Constructors

EOCooperatingObjectStore

public EOCooperatingObjectStore()

Description forthcoming.

Instance Methods

commitChanges

public abstract void commitChanges()

Overridden by subclasses to commit the transaction. Throws an exception if an error occurs; the error message indicates the nature of the problem.

See Also: ownsGlobalID, commitChanges, saveChangesInEditingContext (EOObjectStoreCoordinator)

handlesFetchSpecification

public abstract boolean handlesFetchSpecification(EOFetchSpecification fetchSpecification)

Overridden by subclasses to return true if the receiver is responsible for fetching the objects described by fetchSpecification. For example, EODatabaseContext (EOAccess) determines whether it's responsible based on fetchSpecification's entity name.

See Also: ownsGlobalID, ownsObject

lock

public abstract void lock()

Conformance to NSLocking.

ownsGlobalID

public abstract boolean ownsGlobalID(EOGlobalID globalID)

Overridden by subclasses to return true if the receiver is responsible for fetching and saving the object identified by globalID. For example, EODatabaseContext (EOAccess) determines whether it's responsible based on the entity associated with globalID.

See Also: handlesFetchSpecification, ownsObject

ownsObject

public abstract boolean ownsObject(EOEnterpriseObject anEO)

Overridden by subclasses to return true if the receiver is responsible for fetching and saving anEO. For example, EODatabaseContext (EOAccess) determines whether it's responsible based on the entity associated with anEO.

See Also: ownsGlobalID, handlesFetchSpecification

performChanges

public abstract void performChanges()

Overridden by subclasses to transmit changes to the receiver's underlying database. Raises an exception if an error occurs; the error message indicates the nature of the problem.

See Also: commitChanges, rollbackChanges, saveChangesInEditingContext (EOObjectStoreCoordinator)

prepareForSaveWithCoordinator

public abstract void prepareForSaveWithCoordinator( EOObjectStoreCoordinator coordinator, EOEditingContext anEditingContext)

Overridden by subclasses to notify the receiver that a multi-store save operation overseen by coordinator is beginning for anEditingContext. For example, the receiver might prepare primary keys for newly inserted objects so that they can be handed out to other EOCooperatingObjectStores upon request. The receiver should be prepared to receive the messages recordChangesInEditingContext and recordUpdateForObject.

After performing these methods, the receiver should be prepared to receive the possible messages ownsGlobalID and then commitChanges or rollbackChanges.

recordChangesInEditingContext

public abstract void recordChangesInEditingContext()

Overridden by subclasses to instruct the receiver to examine the changed objects in the receiver's EOEditingContext, record any operations that need to be performed, and notify the receiver's EOObjectStoreCoordinator of any changes that need to be forwarded to other EOCooperatingObjectStores.

recordUpdateForObject

public abstract void recordUpdateForObject( EOEnterpriseObject anEO, NSDictionary changes)

Overridden by subclasses to communicate from one EOCooperatingObjectStore to another (through the EOObjectStoreCoordinator) that changes need to be made to an anEO. For example, an insert of an object in a relationship property might require changing a foreign key property in an object owned by another EOCooperatingObjectStore. This method is primarily used to manipulate relationships.

rollbackChanges

public abstract void rollbackChanges()

Overridden by subclasses to roll back changes to the underlying database. Raises one of several possible exceptions if an error occurs; the error message should indicate the nature of the problem.

See Also: commitChanges, ownsGlobalID, saveChangesInEditingContext (EOObjectStoreCoordinator)

unlock

public abstract void unlock()

Conformance to NSLocking.

valuesForKeys

public abstract NSDictionary valuesForKeys( NSArray keys, EOEnterpriseObject anEO)

Overridden by subclasses to return values (as identified by keys) held by the receiver that augment properties in anEO. For instance, an EODatabaseContext (EOAccess) stores foreign keys for the objects it owns (and primary keys for new objects). These foreign and primary keys may well not be defined as properties of the object. Other database contexts can find out these keys by sending the database context that owns the object a valuesForKeys message. Note that you use this for properties that are not stored in the object, so using key-value coding directly on the object won't always work.