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: Bill Bumgarner <email@hidden>
- Date: Sun, 26 Nov 2006 10:59:51 -0800
On Nov 26, 2006, at 10:16 AM, Remco Poelstra wrote:
Hi,
In general, you should probably keep the bounds and boundsAsString
attributes in sync. Or more carefully track when they are not. I
haven't looked at the code closely, but a quick glance would
indicate that there may be situations where the two could fall out
of sync, leading to problems.
The Core data programming guide advices this way when the instance
variable is accessed often. The string attribute should be updated
when the object is saved, so it doesn't really need to stay in sync
during operation, it's only used for storage.
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.
Your add and remove methods seem overly complex at first glance.
Why not just:
- (void)removeYesChild:(MSChartElement *)value
{
[[self mutableSetValueForKey: @"yesChildren"] removeObject: value];
}
I need to update the relationships when an object is added or
removed, so that's why the methods are a bit complex. They are
mostly "inspired" by the Core Data Programming Guide.
The whole problem is the fact that each entity has two children but
only one parent as the inverse. Core Data doesn't support that
directly, so I try to handle relationships in my own code.
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.
This is a bit scary. It means that *any* key set with a nil value
is going to get a string representation of the {0,0,0,0} rect.
Probably not what you want.
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....
b.bum
_______________________________________________
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