From: Randall S. <ra...@tn...> - 2006-01-06 22:15:52
|
Oleg Broytmann wrote: > On Thu, Jan 05, 2006 at 04:57:09PM -0600, Randall Smith wrote: > >># These only work if a multiple join is already defined. >>A.select(multiple_join=(C.q.name == 'dog', )) >>A.select(multiple_join=(B.q.status == 'A', C.q.name == 'dog')) >>Z.select(multiple_join=(B.q.status == 'A', )) > > > What is "multiple_join" and how it differes from "join"? > > Oleg. Oleg, I thought some more about this today. Say you use the join syntax. Normally, you would pass a list of SQLJoin instances. Say instead, you passed in a list of SQLObject instances or sqlbuilder.SQLOp instances. This would say to SQLObject, I'm not gonna tell you how they're related (No SQLJoin instances). Here is the criteria. Find out if and how they are related and get my data. Would look like this: You have classes A-Z all related by MultipleJoin joins. A = A.get(1) Zs = Z.select(join=[A, ]) Or, do this. Zs = Z.select(join=[A.q.name == 'Sara', ]) Since there is only one path from A to Z using MultipleJoins, this will join all of the tables and return instances of Z in a list. The two classes, A and Z, could be related in more than one way. To say it another way, there may be many paths between A and Z. In that case an unspecific join request could raise an Exception or return False or something. I don't know a good way to specify which path to take, because these paths could potentially be complex using several different types of joins along the way. From my experience, the INNER JOIN would benefit most from this. It would be neat to have a program find all paths between all objects. Some may even be circular. This just seems so cool and very very useful to me. I wonder if it's been done somewhere else. Does hibernate to this? It would be awesome if SQLObject broke new ground here. Randall |