Re: Core Data guidance Was: Calling processPendingChanges from awakeFromInsert
Re: Core Data guidance Was: Calling processPendingChanges from awakeFromInsert
- Subject: Re: Core Data guidance Was: Calling processPendingChanges from awakeFromInsert
- From: Tony Becker <email@hidden>
- Date: Fri, 21 Sep 2007 09:55:24 -0400
I filed a bug report requesting a best practices document, and
included this issue.
Another, similar issue is calling save: in observeChange, which calls
processpendingChanges, which calls observeChange:, ...
Basically, you need to be aware of what the methods do, to prevent
recursion in the stack, which produces undesirable results.
On Sep 20, 2007, at 10:26 PM, mmalc crawford wrote:
On Sep 20, 2007, at 5:56 PM, Brian Williams wrote:
Have the core data docs people though about a section specifically
explaining
what you should and shouldn't do when and where. Maybe in the
context of the
object and document life cycles. Including the gotchas like the
side effects of
undo redo etc... I really could have used some architecture
guidance with my
first CD projects.
As ever, if there are areas which you think need additional
explanation, please file a bug report.
One of the problems, though, with specifying "what you should and
shouldn't do when and where" is that it's at least sometimes
context-dependent. And people have a tendency not to consider the
context -- "Oh, the docs said that, so {I'll do, I won't do} it".
It's not possible to elaborate all the possible circumstances in
which API might be used. *In general*, it is only realistic to
describe principles and guidance as to how they should be applied.
Moreover, particularly with Core Data and other high-level
technologies, the documentation is unlikely to repeat information
that is considered to be prerequisite, and it probably won't
describe interactions between technologies except where there are
significant differences in behaviour (e.g. the Core Data
documentation won't in general describe interaction with key-value
observing except for cases such as the fact that managed objects do
not adopt automatic KVO)...
mmalc
_______________________________________________
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
_______________________________________________
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