public com.netbracketsfw.model.Game createGamesRelationship() {
EOClassDescription eoClassDesc = EOClassDescription.classDescriptionForEntityName("Game");
EOEnterpriseObject eo = eoClassDesc.createInstanceWithEditingContext(editingContext(), null);
editingContext().insertObject(eo);
addObjectToBothSidesOfRelationshipWithKey(eo, "Games");
return (com.netbracketsfw.model.Game) eo;
}
Which editing context is being retrieved by the editingContext() call? Since the object is being added to that editingContext, how do I get a hold of it from outside the class? And finally, why isn't the editing context passed in, as is done in a lot of the other generated operations?
Thanks,
Jeff
On Apr 6, 2008, at 11:06 AM, David LeBer wrote:
On 6-Apr-08, at 12:03 PM, David LeBer wrote:
On 6-Apr-08, at 11:14 AM, Jeff Schmitz wrote:
As I read on, I'm guessing that "the cache" they refer to is actually the "Snapshot" of the database described as:
"When an EODatabaseContext fetches objects from a database, a snapshot is recorded of the state of the fetched database row. A snapshot is a dictionary of a row’s primary keys, class properties, foreign keys used in relationships that are class properties, and the attributes of an entity that participate in optimistic locking.
You can imagine that an application that fetches hundreds of rows of data builds up a large cache of snapshots. "
And furthermore, editing contexts are usually "per/session" and Snapshots are usually "per/application". Correct?
There is one snapshot are per EOF Stack (centered on an EOObjectStoreCoordinator)[1], and by default there is one EOF stack per application - you can create additional EOF stacks, but snapshots are not automatically synchronized.
That should read: "and by default there is one EOF stack per application instance"
[1]<http://wiki.objectstyle.org/confluence/download/attachments/196869/enterprise-objects-stack-diagram.png>
There is one 'defaultEditingContext' per session, but relying on the defaultEC alone is not recommended as abandoned edit operations may result in dirtied data. In general it is recommended that you 'sandbox' editing operations in their own peer or child EC.
Note: If you create your own ECs you must assume responsibility for correctly locking and unlocking them. For this reason I personally recommend using Project Wonder and it's EC auto-locking.
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org