On 25/07/05, Berthold Höllmann <email@example.com> wrote:
> John Page <firstname.lastname@example.org> writes:
> > Do you need a related join in the Person class as well?
> > My guess is that would make the example work.
> But that won't make sense, because i also need a link from Workpackage
> to Person as well, as in other classes. Alone for the "Project" class.
> Does the related join from "Person" point to the Project.leader or one
> member of Project.steeringCommittee?
It sounds like you are misunderstanding Joins much as I did a couple of weeks ago.
Their names really don't help one understand things.
You need to choose what sort of join to use based on whether the
relationship is one-one, one-many or many-many. Not on how you think
you might want to access the data.
i.e. Suppose every Project has many Person's and every Person might work on several Project's;
then you have a many-many situation, which is implemented using RelatedJoins at both ends.
Suppose every Project has many Person's and every Person works on only
one Project, then the relationship is one-many, which is implemented by
giving each person a ForeignKey('Project'), and if you like you can
give each Project a MultipleJoin('Person') which gives you a list of
the Person's with their foreignkey pointing to this Project.
I know this results in some classes having fields that you think you might never use, but you have to live with that.
To recap, if you have a RelatedJoin on one end, you need one on the other end too.
If you have a ForeignKey at one end, you *can* have a MultipleJoin at the other end if you like.
I hope this helps