Re: Bindings and object-pointer keys
Re: Bindings and object-pointer keys
- Subject: Re: Bindings and object-pointer keys
- From: mmalc crawford <email@hidden>
- Date: Sun, 30 Dec 2007 21:27:09 -0800
On Dec 30, 2007, at 8:23 PM, Seth Pellegrino wrote:
On Leopard: <http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/Foundation/Protocols/NSKeyValueObserving_Protocol/Reference/Reference.html#//apple_ref/occ/clm/NSObject/keyPathsForValuesAffectingValueForKey:
>
Thank you for the link, I wasn't aware the mechanism had changed.
I'm now getting the following error:
Person: A +keyPathsForValuesAffectingValueForKey: message returned a
set that includes a key path that starts with the same key that was
passed in, which is not valid. The property identified by the key
path already depends on the property identified by the key, never
vice versa.
Passed-in key: job
Returned key path set: {(
"job.title",
"job.salary"
)}
"n
The "never vice versa" part of that error message doesn't leave me
much hope. I tried setting up a key jobDependency which acted
exactly like the job key, and then registered "job" as dependent on
jobDependency.title and jobDependency.salary, but no dice. The
application just silently fails, as before. Am I not using
+keyPathsForValuesAffectingValueForKey: properly? Is there a
workaround I'm missing?
This means that one of the keys in the you're returning is the same as
the key passed in. An equivalent mistake would be:
+ (NSSet *)keyPathsForValuesAffectingValueForKey:(NSString *)key
{
NSSet *keyPaths = [super
keyPathsForValuesAffectingValueForKey:key];
if ([key isEqualToString:@"fullName"])
{
NSSet *affectingKeys = [NSSet setWithObjects:@"fullName",
@"firstName", @"department.deptName", nil];
keyPaths = [keyPaths setByAddingObjectsFromSet:affectingKeys];
}
return keyPaths;
}
(notice @"fullName" in the returned set for @"fullName").
I'm afraid my knowledge of Core Data is rather limited. It seems
like it would work wonders for managing my data model, but I have
a few reservations. Namely, none of the built-in persistent stores
meet my needs.
In what way are your needs not met?
I need to write out my file in a format which isn't XML, SQLite, or
a straight binary representation of my object graph.
You can do that with a custom store type on Leopard, or using an in-
memory store on Tiger.
How difficult is it to either query the entire object graph (so I
can write out a file manually)
It's not clear what you mean.
You save changes by sending the managed objet context a save:
message, and the file is saved.
Right, but it is my understanding that this uses a persistent store
to save the data. Basically, my question is how can an in-memory
store be manually written out to disk? Is such a thing even possible?
You have to make sure you have all the objects and archive them
yourself. This is possible, but depending on your schema may be tricky.
Note, though, I wouldn't recommend using Core Data until you have
more experience with Cocoa.
That is indeed a reason I'm hesitant to adopt Core Data. Another
reason I'm hesitant to adopt core data is that it won't solve this
particular problem. I put together a core data version of the
EmployeeManager application, and the same problem is still present.
I suspect the problem is with your implementation per above.
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