• 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: +keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: +keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class


  • Subject: Re: +keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class
  • From: Quincey Morris <email@hidden>
  • Date: Thu, 17 Sep 2009 09:42:34 -0700

On Sep 17, 2009, at 05:44, Doug Knowles wrote:

In a CoreData entity called "Topic", I have a to-many relationship (to other
Topics) called "children" to implement a hierarchy. In a category on Topic,
I have implemented a property called "orderedChildren" which returns a
sorted array of the children. In order to ensure that "orderedChildren" is
recognized as a property of the Topic entity, I have defined
"orderedChildren" as an optional, transient attribute of Topic of unknown
type (since NSArray or id isn't supported). CoreData generates a property
declaration for ""orderedChildren" with type UNKNOWN_TYPE, and I have
#defined UNKNOWN_TYPE as "id" in my precompiled header.

It's not at all obvious that following this strategy (creating the transient attribute) does you any good whatsoever. OTOH, it's not at all obvious that it does any harm WRT to the problem you're having.


What doesn't work is defining a class method
+keyPathsForValuesAffectingOrderedChildren,
which I'd like to use to cause changes in the "children" relationship to
trigger change notifications for "orderedChildren".
keyPathsForValuesAffectingOrderedChildren is never called. (Overriding
keyPathsForValuesAffectingValueForKey: from a category is verboten.)

Prima facie, the reason 'keyPathsForValuesAffectingOrderedChildren' doesn't get called would be that nothing is observing the property. Maybe that aspect deserves attention ahead of the Core Data side of it. Have you tried writing some debugging code that (a) installs a KVO observer on the "orderedChildren" property of a Topic object, and (b) changes the "children" property, to see whether (c) "observeValueForKeyPath:..." is invoked for key "orderedChildren"?


Narrowing the problem definition might be the most useful thing you could do.

Also, sorry if it's a stupid question, but you have checked the console log for exception messages, haven't you? It often happens, with KVO-related problems, that an application can appear to run *almost* correctly after an exception is logged and ignored.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: +keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class
      • From: Doug Knowles <email@hidden>
References: 
 >+keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class (From: Doug Knowles <email@hidden>)

  • Prev by Date: Re: How to create subentity object inheriting from superentity object in core data
  • Next by Date: Re: How to create subentity object inheriting from superentity object in core data
  • Previous by thread: +keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class
  • Next by thread: Re: +keyPathsForValuesAffecting<Key> not working for a category-implemented property on a CoreData class
  • Index(es):
    • Date
    • Thread