EOEditingContext
- Inherits from:
- EOObjectStore : NSObject
- Conforms to:
- EOObserving
- NSLocking
Declared in:
- EOControl/EOEditingContext.h
Class at a Glance
An EOEditingContext object manages a graph of enterprise objects in an application; this object graph represents an internally consistent view of one or more external stores (most often a database).
Principal Attributes
- Set of enterprise objects managed by the EOEditingContext
- Parent EOObjectStore
- Set of EOEditor objects messaged by the EOEditingContext
- A message handler
Creation
- initWithParentObjectStore: | Designated initializer. |
Commonly Used Methods
- objectsWithFetchSpecification: | Fetches objects from an external store. |
- insertObject: | Registers a new object to be inserted into the parent EOObjectStore when changes are saved. |
- deleteObject: | Registers that an object should be removed from the parent EOObjectStore when changes are saved. |
- lockObject: | Attempts to lock an object in the external store. |
- hasChanges | Returns YES if any of the receiver has any pending changes to the parent EOObjectStore. |
- saveChanges | Commits changes made in the receiver to the parent EOObjectStore. |
- revert | Removes everything from the undo stack, discards all insertions and deletions, and restores updated objects to their original values. |
- objectForGlobalID: | Given a globalID, returns its associated object. |
- globalIDForObject: | Given an object, returns its globalID. |
- setDelegate: | Sets the receiver's delegate. |
- parentObjectStore | Returns the receiver's parent EOObjectStore. |
- rootObjectStore | Returns the receiver's root EOObjectStore. |
Class Description
An EOEditingContext object represents a single "object space" or document in an application. Its primary responsibility is managing a graph of enterprise objects. This object graph is a group of related business objects that represent an internally consistent view of one or more external stores (usually a database).
All objects fetched from an external store are registered in an editing context along with a global identifier (EOGlobalID) that's used to uniquely identify each object to the external store. The editing context is responsible for watching for changes in its objects (using the EOObserving protocol) and recording snapshots for object-based undo. A single enterprise object instance exists in one and only one editing context, but multiple copies of an object can exist in different editing contexts. Thus object uniquing is scoped to a particular editing context.
For more information on EOEditingContext, see the sections:
- "Other Classes that Participate in Object Graph Management"
- "Programmatically Creating an EOEditingContext"
- "Using EOEditingContexts in Different Configurations"
- "Fetching Objects"
- "Managing Changes in Your Application"
- "Methods for Managing the Object Graph"
- "General Guidelines for Managing the Object Graph"
- "Using EOEditingContext to Archive Custom Objects in Web Objects Framework"
Constants
In EOEditingContext.h, EOControl defines
the following int
constant
to specifies the order in which editing contexts perform end of
event processing in processRecentChanges.
- EditingContextFlushChangesRunLoopOrdering
Messages with lower order numbers are processed before messages with higher order numbers. In an application built with the Application Kit, the constant order value schedules the editing context to perform its processing before the undo stack group is closed or window display is updated.
EOEditingContext.h also defines NSString constants for the names of the notifications it posts. See the section "Notifications" for more information.
Adopted Protocols
EOObserving
- - objectWillChange:
NSLocking
- - lock
- - unlock
Method Types
- Initializing an EOEditingContext
- - initWithParentObjectStore:
- Fetching objects
- - objectsWithFetchSpecification:
- Committing or discarding changes
- - saveChanges
- - saveChanges:
- - tryToSaveChanges
- - refaultObjects
- - refault:
- - refetch:
- - revert
- - revert:
- - invalidateAllObjects
- Registering changes
- - deleteObject:
- - insertObject:
- - insertObject:withGlobalID:
- - objectWillChange:
- - processRecentChanges
- Checking changes
- - deletedObjects
- - insertedObjects
- - updatedObjects
- - hasChanges
- Object registration and snapshotting
- - forgetObject:
- - recordObject:globalID:
- - committedSnapshotForObject:
- - currentEventSnapshotForObject:
- - objectForGlobalID:
- - globalIDForObject:
- - registeredObjects
- Timestamping snapshots
- + defaultFetchTimestampLag
- + setDefaultFetchTimestampLag:
- - fetchTimestamp
- - setFetchTimestamp:
- Locking objects
- - lockObject:
- - lockObjectWithGlobalID:editingContext:
- - isObjectLockedWithGlobalID:editingContext:
- - setLocksObjectsBeforeFirstModification:
- - locksObjectsBeforeFirstModification
- Undoing operations
- - redo:
- - undo:
- - setUndoManager:
- - undoManager
- Accessing the shared editing context
- - sharedEditingContext
- - setSharedEditingContext:
- Deletion and Validation Behavior
- - setPropagatesDeletesAtEndOfEvent:
- - propagatesDeletesAtEndOfEvent
- - setStopsValidationAfterFirstError:
- - stopsValidationAfterFirstError
- Returning related object stores
- - parentObjectStore
- - rootObjectStore
- Managing editors
- - editors
- - addEditor:
- - removeEditor:
- Setting the delegate
- - setDelegate:
- - delegate
- Setting the message handler
- - setMessageHandler:
- - messageHandler
- Invalidating objects
- - setInvalidatesObjectsWhenFreed:
- - invalidatesObjectsWhenFreed
- Locking
- - lock
- - unlock
- Working with raw rows
- - faultForRawRow:entityNamed:
- Unarchiving from nib
- + defaultParentObjectStore
- + setDefaultParentObjectStore:
- + setSubstitutionEditingContext:
- + substitutionEditingContext
- Nested EOEditingContext support
- - objectsWithFetchSpecification:editingContext:
- - objectsForSourceGlobalID:relationshipName:editingContext:
- - arrayFaultWithSourceGlobalID:relationshipName:editingContext:
- - faultForGlobalID:editingContext:
- - saveChangesInEditingContext:
- - refaultObject:withGlobalID:editingContext:
- - invalidateObjectsWithGlobalIDs:
- - initializeObject:withGlobalID:editingContext:
- Archiving and unarchiving objects
- + encodeObject:withCoder:
- + initObject:withCoder:
- + setUsesContextRelativeEncoding:
- + usesContextRelativeEncoding
Class Methods
defaultFetchTimestampLag
+ (NSTimeInterval)defaultFetchTimestampLag
defaultParentObjectStore
+ (EOObjectStore *)defaultParentObjectStore
See Also: + setDefaultParentObjectStore:
encodeObject:withCoder:
+ (void)encodeObject:(id)object
withCoder:(NSCoder *)encoder
Invoked by an enterprise object object to ask the EOEditingContext to encode object using encoder. For more discussion of this subject, see "Using EOEditingContext to Archive Custom Objects in Web Objects Framework" .
See Also: + initObject:withCoder:, + setUsesContextRelativeEncoding:, + usesContextRelativeEncoding
initObject:withCoder:
+ (id)initObject:(id)object
withCoder:(NSCoder *)decoder
Invoked by an enterprise object object to ask the EOEditingContext to initialize object from data in decoder. For more discussion of this subject, see "Using EOEditingContext to Archive Custom Objects in Web Objects Framework" .
See Also: + encodeObject:withCoder:, + setUsesContextRelativeEncoding:, + usesContextRelativeEncoding
instancesRetainRegisteredObjects
+ (BOOL)instancesRetainRegisteredObjects
setDefaultFetchTimestampLag:
+ (void)setDefaultFetchTimestampLag:(NSTimeInterval)lag
When a new editing context is initialized, it is assigned a fetch timestamp equal to the current time less the default timestamp lag. Setting the lag to a large number might cause every new editing context to accept very old cached data. Setting the lag to too low a value might degrade performance due to excessive fetching. A negative lag value is treated as 0.0.
setDefaultParentObjectStore:
+ (void)setDefaultParentObjectStore:(EOObjectStore
*)store
[EOEditingContext setDefaultParentObjectStore:editingContext]; nibLoaded = [NSBundle loadNibNamed:@"thirdNib" owner:self]; [EOEditingContext setDefaultObjectStore:nil]; // Restore default
A default parent object store is global until it is changed again. For more discussion of this topic, see the chapter "Application Configurations" in the Enterprise Objects Framework Developer's Guide.
See Also: + defaultParentObjectStore
setInstancesRetainRegisteredObjects:
+ (void)setInstancesRetainRegisteredObjects:(BOOL)flag
setSubstitutionEditingContext:
+ (void)setSubstitutionEditingContext:(EOEditingContext
*)anEditingContext
[EOEditingContext setSubstitutionEditingContext:editingContext]; nibLoaded = [NSBundle loadNibNamed:@"thirdNib" owner:self]; [EOEditingContext setSubstitutionEditingContext:nil]; // Restore default
A substitution editing context is global until it is changed again. For more discussion of this topic, see the chapter "Application Configurations" in the Enterprise Objects Framework Developer's Guide.
See Also: + substitutionEditingContext
setUsesContextRelativeEncoding:
+ (void)setUsesContextRelativeEncoding:(BOOL)flag
Sets according to flag whether encodeObject:withCoder: uses context-relative encoding. For more discussion of this subject, see "Using EOEditingContext to Archive Custom Objects in Web Objects Framework" .
See Also: + usesContextRelativeEncoding, + encodeObject:withCoder:
substitutionEditingContext
+ (EOEditingContext *)substitutionEditingContext
See Also: + setSubstitutionEditingContext:
usesContextRelativeEncoding
+ (BOOL)usesContextRelativeEncoding
Returns YES to indicate that encodeObject:withCoder: uses context relative encoding, NO otherwise. For more discussion of this subject, see "Using EOEditingContext to Archive Custom Objects in Web Objects Framework" .
See Also: + setUsesContextRelativeEncoding:
Instance Methods
addEditor:
- (void)addEditor:(id)editor
See Also: - removeEditor:
arrayFaultWithSourceGlobalID:relationshipName:editingContext:
- (NSArray *)arrayFaultWithSourceGlobalID:(EOGlobalID
*)globalID
relationshipName:(NSString *)name
editingContext:(EOEditingContext
*)anEditingContext
When a parent EOEditingContext receives this on behalf of a child EOEditingContext and the EOGlobalID globalID identifies a newly inserted object in the parent, the parent returns a copy of its object's relationship array with the member objects translated into objects in the child EOEditingContext.
For more information on faults, see the EOObjectStore, EODatabaseContext (EOAccess), EOFault, and EOFaultHandler class specifications.
See Also: - faultForGlobalID:editingContext:
committedSnapshotForObject:
- (NSDictionary *)committedSnapshotForObject:(id)object
Returns a dictionary containing a snapshot of object that reflects its committed values (that is, its values as they were last committed to the database). In other words, this snapshot represents the state of the object before any modifications were made to it. The snapshot is updated to the newest object state after a save.
See Also: - currentEventSnapshotForObject:
currentEventSnapshotForObject:
- (NSDictionary *)currentEventSnapshotForObject:(id)object
Returns a dictionary containing a snapshot of object that reflects its state as it was at the beginning of the current event loop. After the end of the current event-upon invocation of processRecentChanges-this snapshot is updated to hold the modified state of the object.
See Also: - committedSnapshotForObject:, - processRecentChanges
delegate
- (id)delegate
See Also: - setDelegate:
deleteObject:
- (void)deleteObject:(id)object
See Also: - deletedObjects
deletedObjects
- (NSArray *)deletedObjects
See Also: - updatedObjects, - insertedObjects
editors
- (NSArray *)editors
See Also: - addEditor:, - removeEditor:
faultForGlobalID:editingContext:
- (id)faultForGlobalID:(EOGlobalID
*)globalID
editingContext:(EOEditingContext
*)anEditingContext
For example, suppose you want the department object whose deptID has a particular value. The most efficient way to get it is to look it up by its globalID using faultForGlobalID:editingContext::
EOEntity *entity = [[[editingContext rootObjectStore] modelGroup] entityNamed:entityName]; EOGlobalID *gid = [entity globalIDForRow:[NSDictionary dictionaryWithObjectsAndKeys:deptIdentifier, @"deptID", nil]]; return [editingContext faultForGlobalID:gid editingContext:editingContext];
If the department object is already registered in the EOEditingContext, this code returns the object (without going to the database). If not, a fault for this object is created, and the object is fetched only when you trigger the fault.
In a nested editing context configuration, when a parent EOEditingContext is sent faultForGlobalID:editingContext: on behalf of a child EOEditingContext and globalID identifies a newly inserted object in the parent, the parent registers a copy of the object in the child.
For more discussion of this method, see the section "Working with Objects Across Multiple EOEditingContexts" . For more information on faults, see the EOObjectStore, EODatabaseContext (EOAccess), EOFault, and EOFaultHandler class specifications.
See Also: - arrayFaultWithSourceGlobalID:relationshipName:editingContext:
faultForRawRow:entityNamed:
- (id)faultForRawRow:(id)row
entityNamed:(NSString *)entityName
Returns a fault for the raw row row by invoking faultForRawRow:entityNamed:editingContext: with self as the editing context.
fetchTimestamp
- (NSTimeInterval)fetchTimestamp
forgetObject:
- (void)forgetObject:(id)object
globalIDForObject:
- (EOGlobalID *)globalIDForObject:object
See Also: - objectForGlobalID:
hasChanges
- (BOOL)hasChanges
initWithParentObjectStore:
- initWithParentObjectStore:(EOObjectStore
*)anObjectStore
self
.
The receiver shares objects with the default shared editing context
(if any) unless you change its shared editing context with setSharedEditingContext:.This
method is the designated initializer for EOEditingContext. For more
discussion of parent EOObjectStores, see "Other Classes that Participate in Object Graph Management" .initializeObject:withGlobalID:editingContext:
- (void)initializeObject:(id)object
withGlobalID:(EOGlobalID *)globalID
editingContext:(EOEditingContext
*)anEditingContext
insertedObjects
- (NSArray *)insertedObjects
See Also: - deletedObjects, - updatedObjects
insertObject:
- (void)insertObject:(id)object
See Also: - insertedObjects, - deletedObjects, - insertObject:withGlobalID:
insertObject:withGlobalID:
- (void)insertObject:object
withGlobalID:(EOGlobalID *)globalID
It is an error to insert an object that's already registered in an editing context unless you are effectively undeleting the object by reinserting it.
See Also: - insertObject:
invalidateAllObjects
- (void)invalidateAllObjects
The final effect of this method is to refault all objects currently in memory. This refaulting in turn releases all objects not retained by your application or by an EODisplayGroup. The next time you access one of these objects, it's refetched from the database.
To flush the entire application's cache of all values fetched from an external store, use a statement such as the following:
[[editingContext rootObjectStore] invalidateAllObjects];
If you just want to discard uncommitted changes but you don't want to sacrifice the values cached in memory, use the EOEditingContext revert method, which reverses all changes and clears the undo stack. For more discussion of this topic, see the section "Methods for Managing the Object Graph" .
See Also: - refetch:, - invalidateObjectsWithGlobalIDs:
invalidateObjectsWithGlobalIDs:
- (void)invalidateObjectsWithGlobalIDs:(NSArray
*)globalIDs
See Also: - invalidateAllObjects
invalidatesObjectsWhenFreed
- (BOOL)invalidatesObjectsWhenFreed
Returns YES to indicate that the receiver clears and "booby-traps" all of the objects registered with it when the receiver is deallocated, NO otherwise. The default is YES. In this method, "invalidate" has a different meaning than it does in the other invalidate... methods. For more discussion of this topic, see the method description for setInvalidatesObjectsWhenFreed:.
isObjectLockedWithGlobalID:editingContext:
- (BOOL)isObjectLockedWithGlobalID:(EOGlobalID
*)globalID
editingContext:(EOEditingContext
*)anEditingContext
See Also: - lockObject:, - lockObjectWithGlobalID:editingContext:, - locksObjectsBeforeFirstModification
lock
- (void)lock
Locks access to the receiver to prevent other threads from accessing it. If the receiver has a sharedEditingContext, the receiver takes a reader lock on it, as well. You should lock an editing context when you are accessing or modifying objects managed by the editing context. The thread-safety provided by Enterprise Objects Framework allows one thread to be active in each EOEditingContext and one thread to be active in each EODatabaseContext (EOAccess). In other words, multiple threads can access and modify objects concurrently in different editing contexts, but only one thread can access the database at a time (to save, fetch, or fault).
This method creates an NSAutoreleasePool that is released when unlock is called. Consequently, objects that have been autoreleased within the scope of a lock/unlock pair may not be valid after the unlock.
// The following code is WRONG! [editingContext lock]; objects = [editingContext objectsWithFetchSpecification:fetchSpec]; title = [[objects objectAtIndex:0] valueForKey:@"title"]; [editingContext unlock]; NSLog(title); // WARNING: title might not be valid here. // This code is CORRECT. [editingContext lock]; objects = [editingContext objectsWithFetchSpecification:fetchSpec]; title = [[[objects objectAtIndex:0] valueForKey:@"title"] retain]; [editingContext unlock]; NSLog(title); [title release]
Similarly, when you catch exceptions, you need to retain the local exception before raising because the exception is in the lock's pool.
lockObject:
- (void)lockObject:(id)anObject
NSInvalidArgumentException
if
it can't find the globalID for anObject to
pass to lockObjectWithGlobalID:editingContext:.See Also: - isObjectLockedWithGlobalID:editingContext:, - locksObjectsBeforeFirstModification
lockObjectWithGlobalID:editingContext:
- (void)lockObjectWithGlobalID:(EOGlobalID
*)globalID
editingContext:(EOEditingContext
*)anEditingContext
NSInternalInconsistencyException
if unable
to obtain the lock. This method works by forwarding the message lockObjectWithGlobalID:editingContext: to
its parent object store.See Also: - lockObject:, - isObjectLockedWithGlobalID:editingContext:, - locksObjectsBeforeFirstModification
locksObjectsBeforeFirstModification
- (BOOL)locksObjectsBeforeFirstModification
See Also: - setLocksObjectsBeforeFirstModification:, - isObjectLockedWithGlobalID:editingContext:, - lockObject:, - lockObjectWithGlobalID:editingContext:
messageHandler
- (id)messageHandler
See Also: - setMessageHandler:
objectForGlobalID:
- (id)objectForGlobalID:(EOGlobalID
*)globalID
See Also: - globalIDForObject:
objectsForSourceGlobalID:relationshipName:editingContext:
- (NSArray *)objectsForSourceGlobalID:(EOGlobalID
*)globalID
relationshipName:(NSString *)name
editingContext:(EOEditingContext
*)anEditingContext
objectsWithFetchSpecification:
- (NSArray *)objectsWithFetchSpecification:(EOFetchSpecification
*)fetchSpecification
self
as
the EOEditingContext and returns the result.objectsWithFetchSpecification:editingContext:
- (NSArray *)objectsWithFetchSpecification:(EOFetchSpecification
*)fetchSpecification
editingContext:(EOEditingContext
*)anEditingContext
Overrides the implementation inherited from EOObjectStore to fetch objects from an external store according to the criteria specified by fetchSpecification and return them in an array. If one of these objects is already present in memory, this method doesn't overwrite its values with the new values from the database. This method raises an exception if an error occurs; the error message indicates the nature of the problem.
When an EOEditingContext receives this message, it forwards the message to its root object store. Typically the root object store is an EOObjectStoreCoordinator with underlying EODatabaseContexts. In this case, the object store coordinator forwards the request to the appropriate database context based on the entity name in fetchSpecification. The database context then obtains an EODatabaseChannel and performs the fetch, registering all fetched objects in anEditingContext or in the receiver if anEditingContext isn't provided. (Note that EODatabaseContext and EODatabaseChannel are defined in EOAccess.)
objectWillChange:
- (void)objectWillChange:(id)object
parentObjectStore
- (EOObjectStore *)parentObjectStore
processRecentChanges
- (void)processRecentChanges
propagatesDeletesAtEndOfEvent
- (BOOL)propagatesDeletesAtEndOfEvent
See Also: - setPropagatesDeletesAtEndOfEvent:
recordObject:globalID:
- (void)recordObject:(id)object
globalID:(EOGlobalID *)globalID
redo:
- (void)redo:(id)sender
Sends editingContextWillSaveChanges: messages to the receiver's editors, and sends a redo message to the receiver's NSUndoManager, asking it to reverse the latest undo operation applied to objects in the object graph.
See Also: - undo:
refault:
- (void)refault:(id)sender
Sends editingContextWillSaveChanges: messages to the receiver's editors, and invokes refaultObjects.
refaultObject:withGlobalID:editingContext:
- (void)refaultObject:(id)anObject
withGlobalID:(EOGlobalID *)globalID
editingContext:(EOEditingContext
*)anEditingContext
Overrides the implementation inherited from EOObjectStore to refault the enterprise object object identified by globalID in anEditingContext. This method should be used with caution since refaulting an object does not remove the object snapshot from the undo stack. Objects that have been newly inserted or deleted should not be refaulted.
The main purpose of this method is to break retain cycles between enterprise objects. This means that you might still need to break retain cycles to help keep your application's memory in check. For example, suppose you have an Employee object that has a to-one relationship to its Department, and the Department object in turn has an array of Employee objects. You can use this method to break the retain cycle. Note that retain cycles are automatically broken if the EOEditingContext is finalized. For more discussion of this topic, see the section "Methods for Managing the Object Graph" .
refaultObjects
- (void)refaultObjects
refetch:
- (void)refetch:(id)sender
registeredObjects
- (NSArray *)registeredObjects
removeEditor:
- (void)removeEditor:(id)editor
See Also: - addEditor:
reset
- (void)reset
Forgets all objects and makes them unusable. If instancesRetainRegisteredObjects is YES, an invocation of this method is necessary to get the editing context to release all of its registered objects. This method also resets the fetchTimestamp as if the editing context were just initialized.
revert
- (void)revert
Removes everything from the undo stack, discards all insertions and deletions, and restores updated objects to their last committed values. Does not refetch from the database. Note that revert doesn't automatically cause higher level display groups (WebObject's WODisplayGroups or the interface layer's EODisplayGroups) to refetch. Display groups that allow insertion and deletion of objects need to be explicitly synchronized whenever this method is invoked on their EOEditingContext.
See Also: - invalidateAllObjects
revert:
- (void)revert:(id)sender
rootObjectStore
- (EOObjectStore *)rootObjectStore
saveChanges
- (void)saveChanges
Sends editingContextWillSaveChanges: messages to the receiver's editors, and commits changes made in the receiver to its parent EOObjectStore by sending it the message saveChangesInEditingContext:. If the parent is an EOObjectStoreCoordinator, it guides its EOCooperatingObjectStores, typically EODatabaseContexts, through a multi-pass save operation (see the EOObjectStoreCoordinator class specification for more information). If a database error occurs, an exception is raised. The error message indicates the nature of the problem.
saveChanges:
- (void)saveChanges:(id)sender
See Also: - editingContext:presentErrorMessage:(EOMessageHandlers), - editingContext:shouldPresentException: (EOEditingContext Delegate)
saveChangesInEditingContext:
- (void)saveChangesInEditingContext:(EOEditingContext
*)anEditingContext
setDelegate:
- (void)setDelegate:(id)anObject
See Also: - delegate
setFetchTimestamp:
- (void)setFetchTimestamp:(NSTimeInterval)timestamp
Note: Changing the fetch timestamp has no effect on existing objects in the editing context; it can affect only subsequent fetches. To refresh existing objects, invoke refaultObjects before you invoke setFetchTimestamp:. |
The initial value for the fetch timestamp of a new non-nested editing context is the current time less the defaultFetchTimestampLag. A nested editing context always uses its parent's fetch timestamp. setFetchTimestamp: raises if it's invoked on a nested editing context.
setSharedEditingContext:
- (void)setSharedEditingContext:(EOSharedEditingContext
*)sharedEC
setInvalidatesObjectsWhenFreed:
- (void)setInvalidatesObjectsWhenFreed:(BOOL)flag
Sets according to flag whether the receiver clears and "booby-traps" all of the objects registered with it when the receiver is deallocated. If an editing context invalidates objects when it's deallocated, it sends a clearProperties message to all of its objects, thereby breaking any retain cycles between objects that would prevent them from being deallocated. This method leaves the objects in a state in which sending them any message other than dealloc or release raises an exception.
The default is YES, and as a general rule, this setting must be YES for enterprise objects with cyclic references to be freed when their EOEditingContext is freed.
Note that the word "invalidate" in this method name has a different meaning than it does in the other invalidate... methods, which discard object values and refault them.
See Also: - invalidatesObjectsWhenFreed
setLocksObjectsBeforeFirstModification:
- (void)setLocksObjectsBeforeFirstModification:(BOOL)flag
You should avoid using this method or pessimistic locking in an interactive end-user application. For example, a user might make a change in a text field and neglect to save it, thereby leaving the data locked in the server indefinitely. Consider using optimistic locking or application level explicit check-in/check-out instead.
See Also: - locksObjectsBeforeFirstModification
setMessageHandler:
- (void)setMessageHandler:(id)handler
See Also: - messageHandler
setPropagatesDeletesAtEndOfEvent:
- (void)setPropagatesDeletesAtEndOfEvent:(BOOL)flag
Sets according to flag whether the receiver propagates deletes at the end of the event in which a change was made, or only just before saving changes.
If flag is YES, deleting an enterprise object triggers delete propagation at the end of the event in which the deletion occurred (this is the default behavior). If flag is NO, delete propagation isn't performed until saveChanges is invoked.
You can delete enterprise objects explicitly by using the deleteObject: method or implicitly by removing the enterprise object from an owning relationship. Delete propagation uses the delete rules in the EOClassDescription to determine whether objects related to the deleted object should also be deleted (for more information, see the EOClassDescription class specification and the EOEnterpriseObject interface informal protocol specification). If delete propagation fails (that is, if an enterprise object refuses to be deleted-possibly due to a deny rule), all changes made during the event are rolled back.
See Also: - propagatesDeletesAtEndOfEvent
setStopsValidationAfterFirstError:
- (void)setStopsValidationAfterFirstError:(BOOL)flag
See Also: - stopsValidationAfterFirstError
setUndoManager:
- (void)setUndoManager:(NSUndoManager
*)undoManager
Sets the receiver's NSUndoManager to undoManager. You might invoke this method with nil if your application doesn't need undo and you want to avoid the overhead of an undo stack. For more information on editing context's undo support, see the section "Undo and Redo" .
See Also: - undoManager
sharedEditingContext
- (EOSharedEditingContext *)sharedEditingContext
stopsValidationAfterFirstError
- (BOOL)stopsValidationAfterFirstError
See Also: - setStopsValidationAfterFirstError:
tryToSaveChanges
- (NSException *)tryToSaveChanges
undo:
- (void)undo:(id)sender
Sends editingContextWillSaveChanges: messages to the receiver's editors, and sends an undo message to the receiver's NSUndoManager, asking it to reverse the latest uncommitted changes applied to objects in the object graph. For more information on editing context's undo support, see the section "Undo and Redo" .
See Also: redo:
undoManager
- (NSUndoManager *)undoManager
Returns the receiver's NSUndoManager.
See Also: - setUndoManager:
unlock
- (void)unlock
Unlocks access to the receiver so that other threads may access it. If the receiver has a sharedEditingContext, the receiver unlocks a reader lock on the shared context.
See Also: - lock
updatedObjects
- (NSArray *)updatedObjects
See Also: - deletedObjects, - insertedObjects
Notifications
The following notifications are declared (except where otherwise noted) and posted by EOEditingContext.
EOEditingContextDidSaveChangesNotification
This notification is broadcast after changes are saved to the EOEditingContext's parent EOObjectStore. The notification contains:- Notification Object
- The EOEditingContext
- userInfo
- A dictionary with the following keys (constants defined in EOObjectStore.h) and values
Key | Value |
EOUpdatedKey | An NSArray containing the changed objects |
EOInsertedKey | An NSArray containing the inserted objects |
EODeletedKey | An NSArray containing the deleted objects |
EOInvalidatedAllObjectsInStoreNotification
This notification is defined by EOObjectStore. When posted by an EOEditingContext, it's the result of the editing context invalidating all its objects. When an EOEditingContext receives anEOInvalidatedAllObjectsInStoreNotification
from
its parent EOObjectStore, it clears its lists of inserted, updated,
and deleted objects, and resets its undo stack. The notification
contains:Notification Object | The EOEditingContext |
userInfo Dictionary | None. |
An interface layer EODisplayGroup (not a WebObjects WODisplayGroup) listens for this notification to refetch its contents. See the EOObjectStore class specification for more information on this notification.
EOObjectsChangedInStoreNotification
This notification is defined by EOObjectStore. When posted by an EOEditingContext, it's the result of the editing context processing objectWillChange: observer notifications in processRecentChanges, which is usually as the end of the event in which the changes occurred. See the EOObjectStore class specification for more information onEOObjectsChangedInStoreNotification
.This notification contains:
- Notification Object
- The EOEditingContext
- userInfo
- A dictionary with the following keys (constants defined in EOObjectStore.h) and values
Key | Value |
EOUpdatedKey | An NSArray of EOGlobalIDs for objects whose properties have changed. A receiving EOEditingContext typically responds by refaulting the objects. |
EOInsertedKey | An NSArray of EOGlobalIDs for objects that have been inserted into the EOObjectStore. |
EODeletedKey | An NSArray of EOGlobalIDs for objects that have been deleted from the EOObjectStore. |
EOInvalidatedKey | An NSArray of EOGlobalIDs for objects that have been turned into faults. Invalidated objects are those for which the cached view should no longer be trusted. Invalidated objects should be refaulted so that they are refetched when they're next examined. |
EOObjectsChangedInEditingContextNotification
EOCONTROL_EXTERN NSString *EOObjectsChangedInEditingContextNotification
EOObjectsChangedInStoreNotification
,
except that it contains objects rather than globalIDs. The notification
contains:- Notification Object
- The EOEditingContext
- userInfo
- A dictionary with the following keys (constants defined in EOObjectStore.h) and values
Key | Value |
EOUpdatedKey | An NSArray containing the changed objects |
EODeletedKey | An NSArray containing the deleted objects |
EOInsertedKey | An NSArray containing the inserted objects |
EOInvalidatedKey | An NSArray containing invalidated objects. |
Interface layer EODisplayGroups (not WebObjects WODisplayGroups) listen for this notification to redisplay their contents.