Re: Help with SharedEditingContext...
Re: Help with SharedEditingContext...
- Subject: Re: Help with SharedEditingContext...
- From: LD <email@hidden>
- Date: Fri, 15 Jul 2005 17:11:32 +1000
Hi Art and all,
Firstly, thanks for the thoughts. Secondly, the error has been
tracked down to a _simple_ bug in my code. Bah humbug ;-)
On 15/07/2005, at 4:36 PM, Art Isbell wrote:
On Jul 14, 2005, at 7:27 PM, LD wrote:
Previously, in my Session I was fetching some objects into the
defaultEditingContext and when editing a particular
EOEnterpriseObject I was creating a child editing context and
getting a local instance of the object to adjust. No worries with
that.
However, now I'm fetching into the EOSharedEditingContext in main
- no problems there, but when I get local instances of those
objects in a editing context for a page, a few objects are
mysteriously missing.
I've never used a shared editing context where WOSession's default
editing context seems appropriate.
My reading of the docs (<http://developer.apple.com/documentation/
LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/
Developer/WebObjects/DeltaDoc/EOF.html#CBGCHAIA> or <http://
tinyurl.com/a3meb>) suggests that a shared editing context is
designed to contain shared objects, those that are available to all
sessions, not just in one session.
I perhaps didn't explain that when implementing it - I had indeed
shifted the fetching logic to the Application class and this works
well. e.g.,
public Application() {
<...>
sharedEditingContext =
EOSharedEditingContext.defaultSharedEditingContext();
try {
refetchSharedRecordsForNamedEntity("ProductCategory");
<...>
} catch (Exception e) { <...> }
}
/** @TypeInfo EOEnterpriseObject */
public NSArray sharedRecordsForNamedEntity(String entityName) {
return (NSArray) sharedEditingContext.objectsByEntityName
().valueForKey(entityName);
}
/** @TypeInfo EOEnterpriseObject */
public NSArray refetchSharedRecordsForNamedEntity(String
entityName) {
EOFetchSpecification fetchSpec;
NSArray records;
try {
Class aClass = Class.forName(entityName);
Method aMethod = aClass.getMethod("FetchSpecification",
null);
fetchSpec = (EOFetchSpecification) aMethod.invoke
(aClass, null);
} catch (Exception e) {
fetchSpec = new EOFetchSpecification(entityName, null,
null);
}
try {
records =
sharedEditingContext.objectsWithFetchSpecification(fetchSpec,
sharedEditingContext);
return records;
} catch (RuntimeException rte) {
System.err.println("Refetch error for entity: " +
entityName + " " + rte.getMessage());
rte.printStackTrace(new PrintStream(new FileOutputStream
(FileDescriptor.err)));
}
return NSArray.EmptyArray;
}
With this understanding, I've used shared editing contexts only in
my Application class as a source of read-mostly objects, the
destination objects of whose relationships can only be other shared
objects, and that can be the destination objects of any objects'
relationships. To me, this relegates shared objects to the class of
objects that are stored in what some call code tables; i.e.,
objects that are unlikely to change and that are used to define
other objects.
I agree with the read-mostly usage but am not convinced this limits
shared eo's to code-tables only. i.e., I'm still thinking about this.
e.g., I'm currently planning to use them in relation to a product
catalogue that does indeed change rarely - but will naturally change
over time. This seems to fit the read-mostly criteria. i.e., the
natural thing here is for an Administrator to be able to adjust any
and all information related to the catalogue for such products within
a Session - but for the casual shopper to be able to see the changed
results from their usual direct action browsing.
You state that you "get local instances of those objects in a
editing context for a page".
I'm only using child editing contexts when editing is to occur. So, I
mean using EOUtilities.localInstanceOfObject(eo) so that such changes
can be discarded if the Admin user decides later to "revert such
changes" before the changes are seen globally (i.e., by the session-
less shopper).
If you mean that you are faulting objects from the shared editing
context to another editing context, then you aren't taking
advantage of an important feature of a shared editing context: its
objects do not need to be faulted into an editing context whose
sharedEditingContext() is the shared editing context containing the
objects of interest.
I'll certainly review how I'm using it (just having begun down this
road) but my intention is only to utilise separate ec's when editing
is to occur. But in order to also allow the admin user to rollback
their changes - this I think will mean that their main Session ec
will need to be unhinged from the sharedEC so that until changes are
made permanent the shared Editing Context knows nothing about the
pending changes.
To explain more fully, I am currently utilising two levels of ECs in
Session: (1) the session's defaultEditingContext de-coupled from the
sharedEditingContext for the above reasons, and (2) childEC's of the
main Session EC -- which put their final saves into the Session EC.
In my footer shared component, if global session changes are pending,
the admin user can, at some point, during their editing of the
catalogue make their changes permanent -- at which time the
sharedEditingContext will pick those changes up (i.e., via the usual
Notifications) for the casual browser to see -- but until then the
changes are considered temporary or impermanent.
However, in your code, you are explicitly sending an editing
context a setSharedEditingContext(null) message which will disable
the ability to use shared objects in an editing context without
faulting them in. So I don't understand what advantage using a
shared editing context has in this case.
Basically the sharedEC is not for the benefit of the Session-based
users... but the direct-action session-less users. Admin, session-
based users, only log in to make adjustments, configure shipping etc...
Now that I've explained a bit more of the theory behind the madness,
if you can think of better ways to do this that'd be good to hear.
Thanks again for the thoughts.
with regards,
--
LD
_______________________________________________
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