Re: [SQLObject] search RelatedJoin

[Ian B. <ia...@co...>]

Luke Opperman wrote:
> 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).

Yes, that seems reasonable.  Off the top of my head, I'm guessing it 
could almost be like:

def childrenSelect(self, query, **kw):
     query = query & (self.id == ChildTable.q.thisID)
     return ChildTable.select(query, **kw)

Obviously generalized some, so that it allows for string queries and all 
the other join options.  Joins need to be cleaned up some too, so a 
general refactoring might be good.

Another option for joins was to make them live lists, so that appending 
or removing changed the underlying database.  I'm thinking that might be 
unnecessarily clever, though, and building it on a select would be better.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org