• 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: Saving a core data model to persistent store makes application hang
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 19:16:17 +0100
  • Resent-date: Sun, 26 Nov 2006 19:20:52 +0100
  • Resent-from: Remco Poelstra <email@hidden>
  • Resent-message-id: <email@hidden>
  • Resent-to: email@hidden

Hi,

Thank you for your reply. I made a sample with Sampler instead of Spin Control and then the traces show names indeed: http:// beryllium.net/~remco/MStrace.trace . I hope it's usefull. Seems it has some deadlock somewhere, but it uses 100%CPU so it's not just waiting for another thread. I can't find a link to Core Data, which I expect.

Op 26-nov-2006, om 18:21 heeft Bill Bumgarner het volgende geschreven:
Use your setter method so the KVO notifications are sent properly. Depending on your model, this could also be hosing the context's state management stuff. Speaking of the model, the names of some of your attributes are a bit odd. "child_yes" doesn't really say "the set of children considered to be in the 'yes' state'. How about 'yesChildren' and 'noChildren'? (yes, pedantic, I know.)

I fixed the setter method. I'll think about the renaming, but I would like to find this bug first :)



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.


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.


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.

Thanks again,

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


  • Prev by Date: Hiding & Showing Table View Columns?
  • Next by Date: Re: Saving a core data model to persistent store makes application hang
  • Previous by thread: Re: Hiding & Showing Table View Columns?
  • Next by thread: NSView's origin
  • Index(es):
    • Date
    • Thread