Core Data Confusion

[Marcus S. Zarra]

Short answer is no

It is not a bad thing to be accessing the primitive values in this  
situation.  I believe that warning was for external access to the  
values.  e.g. object A should be calling -getValueForKey: instead of - 
getPrimitiveValueForKey: on object B.  This ensures that object B has  
complete control over what happens when that value is accessed.

Marcus S. Zarra
Zarra Studios LLC
Simply Elegant Software for OS X
www.zarrastudios.com

On Jan 31, 2007, at 10:32 AM, 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?
> --
> 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
>
>
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev at omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev