Re: Saving a core data model to persistent store makes application hang
Re: Saving a core data model to persistent store makes application hang
- Subject: Re: Saving a core data model to persistent store makes application hang
- From: Remco Poelstra <email@hidden>
- Date: Sun, 26 Nov 2006 20:47:04 +0100
Op 26-nov-2006, om 19:59 heeft Bill Bumgarner het volgende geschreven:
On Nov 26, 2006, at 10:16 AM, Remco Poelstra wrote:
Yup -- 'tis an optimization and I agree that keeping the two in
sync all the time will be a significant performance hit. My poorly
stated point was that you need to be very careful about keeping
them in sync when it is appropriate to have them in sync, including
ensuring that the various change notifications are set up correctly.
I believe that it will be correct then, since I copied the structure
from the guide.
Core Data does support inverse relationships in that you can have a
one-to-many and an inverse relationship of a one-to-one.
Have a look at the OutlineEdit CoreData example included with the
dev tools. The Note entity has a one-to-many "children"
relationship with a one-to-one "parent" relationship. The two
relationships are inverses of each other.
You can also specify-- can model using the Core Data modeling tools
in Xcode -- that two different to-many relationships have the same
inverse to-one relationship (I just tested this by adding a
"cousins" relationship configured identically to "children" in the
OutlineEdit project). It should *just work*. If it doesn't, file
a bug, please.
When I add a relation called "cousins" the "children" relation loses
it's connection to the "parent" inverse. Is that what you mean? Is it
just that Xcode doesn't show the children-parent connection, while it
is there?
Oops, yes, added a check for the key.
The samples look like your program is drowning in a notification
storm. Without knowing the size of the object graph, etc, it is
hard to tell if this is "normal" processing (that you could
restructure your code slightly to optimize away) or you have set up
a situation where a change notification is, itself, triggering a
change that causes a second change notification, causing
etc.etc.etc....
The object graph only contains one instance when I test it. I've made
a screenshot of the model, perhaps it will help: http://beryllium.net/
~remco/Image1.png
Your idea about a notification triggering itself brought me the idea
to surround all Chart_elements methods with an NSLog statement,
outputting the method name. I get the following output when I have
only one instance in the object graph:
2006-11-26 20:40:47.672 MusicStructure[1271] bounds called
2006-11-26 20:40:47.672 MusicStructure[1271] bounds finished
2006-11-26 20:40:47.673 MusicStructure[1271] parent called
2006-11-26 20:40:47.673 MusicStructure[1271] parent finished
2006-11-26 20:40:47.673 MusicStructure[1271] willsave called
2006-11-26 20:40:47.675 MusicStructure[1271] willsave finished
After this it simply keeps repeating. So there seems to be nothing
wrong with the relations, at least, it only requests the parent
relation. But why would it keep on looping over that one object?
Thanks,
Remco Poelstra
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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