Well, I have to admit to dealing with this problem, in not very nice ways, and
not trying to find a better solution for SO yet. So this idea is not directly
supported, but...
First, I define an SO class for the intersection, DogPerson or something more
meaningful like DogOwners. Whatever. And define it as though it has
foreignKeys to Dog and Person, and whatever other attrs.
Then Person and Dog each have MultipleJoins to this class. aDog.owners or
aPerson.ownedDogs gives access to the intersection objects. Each main class
also gets a RelatedJoin to the other. This just facilitates shortcut access
(aDog.persons == [ x.person for x in aDog.owners ] ).
I think that about covers it. Something makes me think there are also cases
where I've done a version of joinWhere (aDog.ownersWhere('otherAttr = x')),
but I can't think of why now, and it probably was due to the more general
desire for joinWhere than anything to do with intersection records.
Having written this up, I can't think of how I'd really clean this up to be
more directly supported... Thoughts? The RelatedJoin shortcut might be able to
be cleared up, to be more of a generic multiple-level-join shortcut thing, but
other than that... I guess I kind of like it.
- Luke
P.S. joinWhere... just a combination of select and join behaviors, but accessed
more like a parameterized join. I ought to hurry up and make this code more
generic, as I think other people have asked for similar functionality..
|