Core Data Confusion

[Christiaan Hofman]

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
>
>
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev at omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev