From: Luke O. <lu...@me...> - 2004-11-10 08:05:19
|
Quoting Ksenia Marasanova <kse...@gm...>: > > Now another question: how to search RelatedJoin? I have a table > Address with many-to-many relation to it self. Address kan have > multiple addresses as parents, and can be a parent on it's own. I'd > like to find all children of given parent. How should I build this > query with SQLObject? > As Ian says, if you're looking for _all_ the ancestors of a recursive structure like this, or an arbitrary distance in the tree, it's messy and there is probably bookkeeping info that will make it more manageable. If you just need direct children, RelatedJoin should do it for you, just have one for the parents and one for the children. Address --> [childID|parentID] <-- Address class Address(SQLObject): # col defs #... children = RelatedJoin('Address', joinColumn='parentID', otherColumn='childID') parents = RelatedJoin('Address', joinColumn ='childID', otherColumn='childID') Your question brings another one to mind, about additional criteria on the select used for joins (both RelatedJoin and MultipleJoin). Using your relationships: All children addresses with zipcode '98661' All parent addresses in the same city as the current record. I know I've mentioned this before, so this is more a reminder to myself - I keep finding reasons for this, but it's easy enough to work around, just a duplication of knowledge about what the joinColumns names are. It needs to take at least a query argument, and should probably take most of the select() arguments. Either an additional public method (joinMethodNameSelect perhaps) or an internal method of the join (which would need a better way to retrieve join objects - self._joinNames['joinMethodName'].select perhaps). If there's interest, I can take this on, since I've been using this idea so many times lately (on RelatedJoins) but working my way around by manually rebuilding the select statement. This way I could define: def childrenWithZipcode(self, zip): return self.childrenSelect(Address.q.zipcode == zip) def _get_parentsInSameCity(self): return self.parentsSelect(Address.q.city == self.city) RelatedJoins, and your self-referential example in particular, show the difficulty in this. If it were a MultipleJoin, say People to many addresses, the query would default to the query against the foreign table, no need to specify 'address.city', just 'city'. But in these examples, you'd either have to specify that clauseTables always apply to the joining side, or give a way to distinguish between the two sides of the join. And the selects for joins might actually have to be joins. :) Hmm. Easy enough to implement for MultipleJoins, messier syntax to decide on for RelatedJoins but still looks possible to me. Ian, any further plans for/against making Joins into fuller SelectResults-like objects? - Luke |