There is an array of 'Person' objects, each of whom has a name and a
job. Each Job is uniquely defined by a title (i.e. two Jobs are
considered equal if their title strings are equal) and has a salary.
Every person who shares a job has a pointer to exactly the same job
object.
This is a bad idea for several reasons. I'll touch on the most
relevant: This is poor object-oriented design. There should be a
separate Job class. You don't need to compare equality if you can do
something like this:
(personOne.job == personTwo.job)
Your approach is needlessly complicated, difficult to maintain, and
prone to huge problems if your project gains complexity. Separate and
encapsulate things properly from the beginning and you'll have far
fewer headaches.
Also, in business, a salary is typically not a function of a job
that can have more than one position within a company. What if you
have two "Computer Technicians" and one has been with the company for
a few years while the other just started? If you're not giving your
employees slight raises each year, they're going to quit. How do you
maintain separate scales? Salary is typically assigned to the employee
(your Person instances).
In general, your model seems as though it could benefit from Core
Data. I strongly recommend checking it out. With proper design, Job
has a to-many relationship to Person and Person has a to-one
relationship to Job. Core Data takes care of this kind of thing
automatically and everything beautifully fits together.
The salary column won't update until the next time the employees
table becomes key.
The reason for this problem is also rather simple -- technically,
the person's job property (to which the 'salary' table column is
bound) doesn't change.
You need to define a dependent key. Look up -
setKeys:triggerChangeNotificationsForDependentKey: in the documentation.
More generally, you need to spend some time with the documentation.
Look up "Key Value Observing" and read all related material. If you
don't understand this, best not to use Bindings or Core Data at all.
They are prerequisite knowledge.
--
I.S.
_______________________________________________
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
