Re: How to correctly share objects
Re: How to correctly share objects
- Subject: Re: How to correctly share objects
- From: Art Isbell <email@hidden>
- Date: Fri, 24 Feb 2006 09:37:46 -1000
On Feb 24, 2006, at 5:07 AM, Randy Wigginton wrote:
Hello all, I thought I knew how to do this, but apparently I am
mistaken.
<http://developer.apple.com/documentation/LegacyTechnologies/
WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/
DeltaDoc/EOF.html#CBGCHAIA> is the best explanation that I have found.
I have a schema that has a couple of tables with extremely common
objects. These tables usually have two columns, id and meaning; as
an example, I might have three entries, one for "Enabled", another
"Disabled", and "Missing". When my app starts up I load all
objects from the DB and store the objects in a hash map for easy
retrieval later. In the EOModel, I specify to share all objects.
I've been afraid to use an external data structure like a hash map
to store shared objects in WO's multithreaded environment :-)
EOSharedEditingContext stores shared objects in internal
NSDictionaries which provide hashed access like a hash map. Shared
objects can be accessed using EOSharedEditingContext's
objectsByEntityName() or objectsByEntityNameAndFetchSpecificationName().
Objects marked as shared in an eomodel are automatically loaded into
the default EOSharedEditingContext when the eomodel is first accessed
by your app. I haven't tested this lately, but maybe back in the WO
5.1 period, explicitly fetching shared objects would trigger the
automatic fetching of all shared objects *including those that you
explicitly fetched* thus resulting in a double fetch of the shared
objects that you explicitly fetched. My workaround was not to mark
one shared entity as shared in the eomodel. I would explicitly fetch
this entity into the default EOSharedEditingContext in Application's
constructor which would then trigger the fetching of all remaining
shared objects.
To access a particular shared object, in Application, you might
consider implementing something like:
public EOEnterpriseObject objectWithMeaning(String aMeaning) {
EOEnterpriseObject object;
EOSharedEditingContext editingContext =
EOSharedEditingContext.defaultSharedEditingContext();
// EOSharedEditingContext.objectsByEntityName() is not documented to
be thread-safe.
editingContext.lock();
try {
NSDictionary sharedObjects = editingContext.objectsByEntityName();
NSArray meaningObjects = (NSArray)sharedObjects.objectForKey
(yourEntityName);
EOQualifier qualifier = EOQualifier.qualifierWithQualifierFormat
("meaning like %@", new NSArray(aMeaning));
object = EOQualifier.filteredArrayWithQualifier(meaningObjects,
qualifier).lastObject();
}
catch (Exception anException) {
object = null;
}
finally {
editingContext.unlock();
}
return object;
}
When I am creating new objects in other tables that refer to this
table, I simply add the shared object to the main object:
MyFoo f = new Foo();
f.setStatus(((Application)application()).objectWithMeaning(aMeaning));
ec.insertObject(f);
ec.saveChanges();
This seems a bit heavy-weight for a three-row table which could be
fetched into each Session's default editing context without very much
overhead, but for larger tables, sharing objects can be preferable.
Aloha,
Art
_______________________________________________
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