there's a lot going on here, though an initial idea would be when mapping to a __table__ that is in fact a select(), make that select() in terms of a Table object, not the Inode mapped class. The columns as accessed from the Inode class contain annotations that have special meaning when the ORM constructs queries. Composing a select() out of Inode.__table__ directly will ensure none of these annotations are confusing the issue.
It's hard for me to know more about this as I don't have a full and concise test case, illustrating a minimal mapping as well as the query operation which produces this query. For example I don't see any "lazy", "joinedload()" or "subqueryload()" here though it seems clear some eagerloading is going on. A single file, fully runnable, and only the minimal mappings test case, with all extraneous mappings, columns, and other non-relevant details removed, would be the best vehicle for sharing and discussing the core mapping issue you're experiencing. Another approach that can make this sort of thing a lot easier of course is to map to a database view rather than a select() object. That would move all the complexity of "selecting from a select" over to the database side, in case you're looking for a quick fix. Some hints on maintaining database views with SQLA are at http://www.sqlalchemy.org/trac/wiki/UsageRecipes/Views . -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
