On 25/07/05, Berthold Höllmann <bhoel@despammed.com> wrote:
> John Page <jooohn.page@gmail.com> 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

God bless,
John