Another quick question on EOs if I may. I'm trying to learn all the
in's and out's of the object graph, and am wondering about this code
generated by the EOGenerator, and specifically the call to
editingContext():
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
