[SQLObject] Re: Creating table using "createTable" fails partly?
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: <ber...@de...> - 2005-07-26 13:08:09
|
John Page <joo...@gm...> writes: > On 25/07/05, Berthold Höllmann <bh...@de...> wrote: >> John Page <joo...@gm...> 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. But each "Project" also has "Workpackage"s that have "Subproject"s. The "Workpackage"s and "Subproject"s have leader and deputy leaders that are "Person"s also. So where are the RelatedJoins in "Person" pointing to? To "Project", "Workpackage", or "Subproject"? The "Leader" in one "Workpackage" could be "Leader" for a "Subproject" also or "DeputyLeader" for another "Worpackage", or "Subproject". So it seems to me there is no easy way to model this depenedencies using SQLObject? Berthold > 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 -- __ Address: G / \ L Germanischer Lloyd phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606 fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg |