• 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
CoreData: Avoiding unresolved key path exception with SQLite store?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CoreData: Avoiding unresolved key path exception with SQLite store?


  • Subject: CoreData: Avoiding unresolved key path exception with SQLite store?
  • From: Jim Correia <email@hidden>
  • Date: Wed, 5 Oct 2005 14:59:59 -0400

Previously Melissa Turner wrote:

When your array controller pulls its contents from the database, it does so using an NSFetchRequest with the entity you are requesting, any predicate you have set to specify which instances of that entity you want, and any sort descriptors you have set to describe how the data should be brought back.

[...]

The SQL store on the other hand, compiles the predicate and sort descriptors to SQL, and evaluates the result in the database itself. This is done primarily for speed; databases are much faster at this, it's what they're designed for. But it means that evaluation is happening in a non-Cocoa world, and so sort descriptors (or predicates) which rely on Cocoa simply can't work, and result in exceptions like the one you're seeing.

You may need to subclass NSArrayController so you can have it not pass the sort descriptors to the database and do the sorting after your data has been fetched instead.

What is the best way to avoid this problem?

Is there any hint I can give an NSFetchRequest that says if the fast path through the SQL store doesn't work, please just do it the slower way and don't bother me?

Is there a framework way to pick apart the sort descriptors or predicate to see if all of the keyPaths are persistent attributes (since plain old KV compliant keys, or transient attributes will cause this error)?

Is there a way to catch the failure at runtime and fallback to the old path in a custom subclass? The exception that is raised is an NSInternalConsistencyException, so it doesn't appear very distinct from other possible errors.

Or should I just give up and always do it the "slow" way (execute the fetch request, then post process with the predicate and sort descriptors) for any situation that could possibly cause this to arise?

Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: Core Data - awakeFromInsert
  • Next by Date: NSPersistentDocument Tutorial Question
  • Previous by thread: Re: Convert Windows file path to Mac File path
  • Next by thread: NSPersistentDocument Tutorial Question
  • Index(es):
    • Date
    • Thread