• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Help with SharedEditingContext...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Help with SharedEditingContext... (From: LD <email@hidden>)
 >Re: Help with SharedEditingContext... (From: Art Isbell <email@hidden>)

  • Prev by Date: Re: Help with SharedEditingContext...
  • Next by Date: Re: JavaMail help...
  • Previous by thread: Re: Help with SharedEditingContext...
  • Next by thread: Deployment Problems WO 5.2 2003 Server - "Page Not Found"
  • Index(es):
    • Date
    • Thread