Core Data Confusion

[Christiaan Hofman]

I think the OP meant the remark about KVO the other way around: he  
seems to think that the report is called only because KVO told that  
the underlying data has changed. At least that is what I understood,  
and remarked this assumption is generally incorrect.

Generally, when accessing properties managed by CD, one should use  
the proper non-primitive methods or wrap will/didAccessValueForKey  
methods around the primitive accessors. That's what the docs say, and  
I assume that's for a reason. The reason I can think of is that the  
will/didAccess.. methods make sure to fire the fault (fetch/update  
the value) if necessary. That would make sense to me, knowing that CD  
doesn't fetch properties immediately. Anyway, I don't know what it  
does, and I don't need to know. The only thing I need to know is what  
is in the docs: you better do it make sure the will/didAccess...  
methods are called. HOWEVER, if you choose to use primitive  
accessors, you are responsible to make sure everything is set up  
right. When you also don't use the will/didAccess... methods, you  
have to make sure that everything these methods does (like  
faulting,etc ?) has been taken care of. This DOES mean you need to  
know what these methods do (and you don't, unless you work for Apple,  
but also that is not true, as some framework developer might need to  
subclass these methods).

So to conclude. Can it hurt? The answer is: Yes.

Christiaan

On 3 Feb 2007, at 8:47 PM, Marcus S. Zarra wrote:

> It is true that -valueForKey: does not cause the KVO to fire and  
> that the OP could just use that instead of the primitive  
> accessors.  But it also does not hurt anything, especially if he  
> has some other logic sitting in the -(NSString*)reportName; method  
> that he does not want to fire.
>
> Marcus S. Zarra
> Zarra Studios LLC
> Simply Elegant Software for OS X
> www.zarrastudios.com
>
> On Feb 2, 2007, at 4:07 PM, Christiaan Hofman wrote:
>
>>
>> On 31 Jan 2007, at 6:32 PM, Boisy Pitre wrote:
>>
>>> For the last couple of weeks I have been navigating through the  
>>> Core Data swamp and have made significant progress in my  
>>> understanding of the architecture.  That said, there are a couple  
>>> of things that really have me shaking my head, and I would  
>>> appreciate a second look.
>>>
>>> Real quick: my application is intended to track information about  
>>> animals on different farms.  The data model has three entities:
>>>
>>> 	- FARM <-->> ANIMAL <-->> VACCINATION
>>>
>>> Note the relationships between each entity are to-many going in  
>>> the right direction and to-one going in the left (inverse)  
>>> direction.  A farm can contain many animals and each animal can  
>>> have multiple vaccinations.
>>>
>>> Without getting into too much detail, the FARM entity has a  
>>> transient property report(a string) which depends on other  
>>> attributes in the FARM entity changes.  So the initialize method  
>>> in my FARM Managed Object class is:
>>>
>>> + (void)initialize
>>> {
>>> 	[self setKeys:[NSArray arrayWithObjects:
>>> 											@"farmName",
>>> 											@"managerName",
>>> 											nil]
>>> 	 triggerChangeNotificationsForDependentKey:@"report"];
>>> }
>>>
>>> The attributes farmName and managerName are updated in text  
>>> fields in a window and are updated daily.  The idea is that when  
>>> either of these values change, the report attribute should be  
>>> updated to reflect changes to the names.  My report method:
>>>
>>> - (NSString *)report
>>> {
>>>     NSString * tmpValue = nil;
>>>
>>>     [self willAccessValueForKey: @"report"];
>>> 	tmpValue = [self constructFarmReport];
>>>     [self didAccessValueForKey: @"report"];
>>>
>>>     return tmpValue;
>>> }
>>>
>>>
>>> - (NSString *)constructFarmReport
>>> {
>>> 	NSString *reportString = [[NSString alloc] initWithString:@""];
>>> 	NSString *farm = [self primitiveValueForKey:@"farmName"];
>>> 	NSString *manager = [self primitiveValueForKey:@"managerName"];
>>> 	...
>>>
>>> When the report method is called due to a change in farmName/ 
>>> managerName, it will call constructFarmReport which builds the  
>>> report string and returns it.  Note that I am using the method  
>>> primitiveValueForKey to access the values farmName/managerName  
>>> instead of accessing the identifiers directly.  I've found that  
>>> in the debugger, if I don't use primitiveValueForKey, then the  
>>> willAccessValueForKey/didAccessValueForKey methods get invoked.   
>>> My question is: is using the primitive method to obtain the  
>>> values of these attributes a bad thing?  I know the Core Data  
>>> document discourages one from using the primitive version of the  
>>> call, and encourages use of either valueForKey: or access the  
>>> identifier directly, but if control is already in a method which  
>>> was invoked BECAUSE of KVO, is accessing that variable again  
>>> INSIDE of the observed method a bad thing?
>>
>>
>> Why would it be called JUST because of KVO? If you use the report  
>> property anywhere, it could just be called because the report  
>> value is needed for (inital) display or something. Generally, when  
>> you access a variable in CD you should use valueForKey or call  
>> willAccessValueForKey/didAccessForKey, I don't see any reason why  
>> this situation is any different. I can imagine that CD has to  
>> fetch or update the value for farmName or managerName (I don't  
>> really know how willAccessValueForKey/didAccessForKey are used,  
>> but they can do something).
>>
>> Christiaan
>>
>>> --
>>> Boisy G. Pitre
>>> 337.781.3570 mobile
>>> email: boisy at boisypitre.com
>>> Website: www.boisypitre.com
>>>
>>> "If there is truth to the proposition that knowing the past helps  
>>> us to understand the present, I believe there is at least as much  
>>> truth to the proposition that what we know of the present is  
>>> crucial to our understanding of the past.  What we have not  
>>> ourselves experienced or observed we can at most only partially  
>>> and imperfectly comprehend; and I suspect that there is much in  
>>> history that is so remote from our own experiences or  
>>> observations as to be largely beyond our understanding." -  
>>> Kenneth M. Stamp