Re: Practical EditingContext Design Question
Re: Practical EditingContext Design Question
- Subject: Re: Practical EditingContext Design Question
- From: Lachlan Deck <email@hidden>
- Date: Mon, 20 Feb 2006 10:03:54 +1100
Hi there,
On 17/02/2006, at 3:54 AM, Chuck Hill wrote:
From a posting not too long ago:
Although an EOSharedEditingContext sounds and appears like an
editing context, it's probably a more useful view to consider it a
very special EOObjectStore. I prefer to call it a "read mostly
object store".
i.e., unlike regular ECs, you cannot modify its EOs directly.
Modified EOs are picked up automatically via notifications by the
sharedEC post saveChanges. Newly inserted objects require a refetch
post saveChanges. Anyway, they're particularly convenient for direct-
action based sites or hybrid sites where the proportion of read-only
actions is high.
Several differences.
<...>
Basically, this is a memory-performance compromise. Using a shared
EC means not only do your EOs reuse the cached row level snapshots
in EOAccess, but they are also represented by the same Java
objects. The down side is that shared ECs do more locking, and
changing EOs within them is inconvenient.
It didn't strike me as that inconvenient or even out of the ordinary
to change the EOs within a sharedEC. I liken them, in use, to child
ecs; the only difference being that your ec cannot have a reference
to the shared ec. Otherwise, you get a local copy and save as normal,
telling the shared EC to refetch only for newly inserted objects
saved to the database. The only challenge/dilemma that I can think of
is when running multiple instances of a WOApp. i.e., when/how to
update the other instances. I guess you'd need to implement
notifications.
--- EOs updates ---
EOEditingContext parentEC;
EOEditingContext childEC;
MyEntity me;
EOGlobalID anId;
parentEC = isShared ? null : session().defaultEditingContext();
if ( parentEC != null ) parentEC.lock();
try {
childEC = isShared ? new EOEditingContext() : new EOEditingContext
( parentEC );
childEC.lock();
try {
if ( isShared ) childEC.setSharedEditingContext( null );
me = ( MyEntity )EOUtilities.createAndInsertInstance( childEC,
"MyEntity" );
// .. OR ..
me = ( MyEntity )EOUtilities.localInstanceOfObject( childEC,
existingObjectToModify() );
// modify object
<...>
// changes can easily be thrown away by not saving child ec.
// but if we save here the changes are pushed up to the parent.
childEC.saveChanges();
// and here to the database
if ( ! isShared ) parentEC.saveChanges();
anId = me.globalID();
isNew = ( anId == null || anId.isTemporary() );
if ( isNew ) {
Application.myApplication().refetchSharedObjectsForEntity
( "MyEntity" );
} else {
// NSNotifications take care of refreshing shared object(s)
}
} finally {
childEC.unlock();
}
} catch ( Exception e ) {
...
} finally {
if ( parentEC != null )
parentEC.unlock();
}
In summary, EOSharedEditingContext is really more about
implementation inheritance than interface inheritance.
I thought, in general, it's more about caching and less round-trips
to the database for EOs (e.g., products) that rarely change.
with regards,
--
Lachlan Deck
_______________________________________________
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