• 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: eosharededitingcontext & in memory fetching
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eosharededitingcontext & in memory fetching


  • Subject: Re: eosharededitingcontext & in memory fetching
  • From: Christian Pekeler <email@hidden>
  • Date: Tue, 24 May 2005 14:10:46 -0600

I have read in Apple's docs that when using eosharededitingcontext any normal fetches (i.e. using a fetchSpec) that you have will first look in the eosharededitingcontext for the queried objects and if any or some of the objects are not here only then it will move on to do a full fetch from the database, however,

I've never done this and could be wrong, but I think this is supposed to be used like:


// do this once
sharedEditingContext.bindObjectsWithFetchSpecification(yourFetchSpec, "yourFetchSpecName");


// from now on...
(NSArray)sharedEditingContext.objectsByEntityNameAndFetchSpecificationNa me().valueForKey("yourFetchSpecName");



sometimes I feel as if the application is doing a full fetch regardless as it seems very slow to respond with objects that have actually already been fetched in the shared context. Other times the app runs nice and fast as if it had done an in-memory search.

Turn on EOAdaptorDebugEnabled to see when roundtrips to the DB are happening.



Can anyone point me to good examples of how to do a proper in-memory fetch, correctly

I've been working on a utility class EnterpriseObjectsFetcher which will be released with the next version of WOUnitTTest but can be used by itself. It offers an api similar to the fetch-related methods on EOUtilities, except that it also allows you to specify whether those fetches should go against the database, against the registered objects in the editing context, or against both.


The original motivation was to use EnterpriseObjectsFetcher in collaboration with WOUnitTTest's MockEditingContext to make production code which uses fetch specifications unit testable without too much effort (i.e. without hitting the database when running the tests). But it also turned out to be very useful for verifying uniqueness of EOs and I've already used it for that purpose on a project where I needed to compare EOs against other unsaved new EOs instead of just against old ones in the DB.

You can take a look at the current version here (I'll probably rename the class soon, at which point these links will become stale):
http://tinyurl.com/a9zvk
http://tinyurl.com/89ufq
As you can see from the code, it's not very complicated to run fetch specs in memory. You just need to keep some shortcomings in mind:
- it doesn't work for raw-rows fetches
- hints (custom SQL) can't be considered, the fetch spec's qualifier needs to suffice
- if your qualifier contains a keypath that spans a to-many relationship, be aware that filtering an NSArray will return an array of arrays whereas the DB will return a 'flat' result



Christian

_______________________________________________
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: 
 >eosharededitingcontext & in memory fetching (From: "Jonathan Fleming" <email@hidden>)

  • Prev by Date: Re. Javadoc in xcode 2
  • Next by Date: Re: Empty relationship that isn't null
  • Previous by thread: eosharededitingcontext & in memory fetching
  • Next by thread: Re. Javadoc in xcode 2
  • Index(es):
    • Date
    • Thread