Re: EO Programming Guide ?s
Re: EO Programming Guide ?s
- Subject: Re: EO Programming Guide ?s
- From: David LeBer <email@hidden>
- Date: Wed, 9 Apr 2008 00:01:34 -0400
On 8-Apr-08, at 11:46 PM, Jeff Schmitz wrote:
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?
That method creates a new Game objects and adds it to the
"games" (which should have a lower case "g" by the way) relationship
of the current EO. So the editingContext() call is the same as
this.editingContext(), and returns the editing context of the current
EO.
Since the object is being added to that editingContext, how do I get
a hold of it from outside the class?
MyObject myEO; //assume exists
EOEditingContext ec1 = myEO.editingContext();
Game game = myEO.createGamesRelationship();
EOEditingContext ec2 = game.editingContext();
ec1 == ec2
And finally, why isn't the editing context passed in, as is done in
a lot of the other generated operations?
Because it doesn't need to. The EO you are calling the method on
already has an EC.
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
;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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden