On Jan 23, 2014, at 2:07 PM, Simon King <[email protected]> wrote:
> > That's fantastic, thanks so much. I feel bad that my silly use case > has caused so much work for you and grown the docs even more (perhaps > you need a separate "Tricks for People who Should Know Better" > section) oh but this use case comes up all the time, it’s now that SQLA can really write a decent SELECT for this kind of thing that I felt it was time to make it an official use case on the site. > > If I understand what you've written correctly, the non-primary-mapper > version is the only one that will meet my needs. It seems to be > working well, both lazy and eager loading, and the extra properties > appearing on the class aren't an issue (I'm marking a lot of them as > deferred so as not to load too much from the database). Right, I think the differentiating factor when NP is needed is that you’re joining A->B, there’s any number of C, D in the middle, but also A and B have some direct foreign keys as well. is that the case for you? the non_primary use case could still benefit from some cleanup; the column naming issue as well as the fact that you get those extra columns in your results.
signature.asc
Description: Message signed with OpenPGP using GPGMail
