[Twisted-Python] enterprise.row and two-way relationships
justin at gnubian.org
Sun Oct 20 15:44:33 EDT 2002
On Sun, 2002-10-20 at 13:50, Ken Kennedy wrote:
> On Sat, Oct 19, 2002 at 06:21:32PM -0500, Justin Ryan wrote:
> > Hello..
> > To solve this problem, I've got a 'rel' table which keeps relationships
> > between account ids and contact ids, so if I want all of the contacts
> > for account x I simply pull all of the rows out of the 'rel' table whose
> > accountId is x, and then individually step through them and extract the
> > contacts with the corresponding accountIds..
> > I don't think there is a problem with the way I'm doing this, or a
> > better way to do this (though I'd be tickled if someone could point me a
> > better way), but in any case there does not seem to be an (obvious) way
> > to handle this with RowObjects..
> It's a little unclear, but the "pull all of the rows out..and then
> individually step through them" seems to suggest you're making two
> queries to the db. If that's the case,then yeah, there's a better
> way. If you know the accountID (from some previous query), just join
> rel to contacts:
> "select contact_info from contacts inner join rel on (rel.contactid =
> contacts.contactid) where rel.accountid = whatever"
> If you only know account name info, use:
> "select contact_info from
> accounts inner join rel on (rel.accountid = accounts.accountid)
> inner join
> contacts on (contacts.contactid=rel.contactid)
> where account.accountname = 'whatever'
> Either way, you should be getting back what you need in one
> query. Does that make sense?
Certainly.., and it's not that far off from what I was doing.. except it
does seem a bit off in that no info is actually being pulled from the
account table - and if it were, it would be pulled multiple times (if i
want to pull the account name and account id, and then a list of
the big important question here is ('scuse my german)... *drumroll*
how the fuck do I do this with twisted.enterprise.row? ;)
Unfortunately, the documentation for row seems pretty sketchy and shows
a direct parent-child relationship (room->furniture)..
it seems very unimportant what the underlying SQL does if row is
supposed to abstract it anyway..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20021020/6d081a4a/attachment.pgp
More information about the Twisted-Python