• 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: Practical EditingContext Design Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Practical EditingContext Design Question


  • Subject: Re: Practical EditingContext Design Question
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 16 Feb 2006 08:54:10 -0800

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".

Several differences.

First, correctly locking and unlocking an EC at the application level is your responsibility, regardless of whether or not you believe an operation is "an edit". For example, firing a fault causes side effects upon various caches. EOSharedEditingContexts manage their own locking.

Second, EOSharedEditingContexts are "read mostly". Mutating EOs in them is complicated and inefficient.

Third, regular ECs "have" one shared EC, a lot like they have a parent object store. This means that several regular ECs all using the same shared EC also use the same objects that are within the shared EC. EOs within a shared EC are unique instances, unlike all other EOs which have individual instances in each regular EC, even though they have the same primary key (GID).

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.

In summary, EOSharedEditingContext is really more about implementation inheritance than interface inheritance.

Ben Trumbull


Chuck

On Feb 16, 2006, at 8:42 AM, Rico Landefeld wrote:

hi,


No. While the EOSharedEditingContext is, technically, instanceof EOEditingContext it is _not_ a proper editing context and should not be used as one. You will run into trouble doing that. It is a shared, read-mostly, object store. Someone at Apple got a little lazy and did implementation inheritance instead of holding a reference to an EC or something similar.


could you explain this a little bit deeper? what did you mean with an EOSharedEditingContext is not a proper editing context?

regards,
rico


--
Coming in 2006 - an introduction to web applications using WebObjects and Xcode http://www.global-village.net/wointro


Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects




_______________________________________________ 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
  • Follow-Ups:
    • Re: Practical EditingContext Design Question
      • From: Lachlan Deck <email@hidden>
References: 
 >Practical EditingContext Design Question (From: email@hidden)
 >Re: Practical EditingContext Design Question (From: Arturo Perez <email@hidden>)
 >Re: Practical EditingContext Design Question (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Practical EditingContext Design Question
  • Next by Date: Re: No Instance issue from WebPDFReports 1.0
  • Previous by thread: Re: Practical EditingContext Design Question
  • Next by thread: Re: Practical EditingContext Design Question
  • Index(es):
    • Date
    • Thread