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?
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.
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?
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.
