I agree with Simon, and I think I'm very much -1 on the usage of contains_eager above (and I think that ticket you linked to, Mike). I find that sort of stuff causes a lot of bugs in the long run.
I am looking at it from this perspective, which is the same as Simon's but some stronger language... The relationship `User.addresses` is specified as the logical relationship of a User to *all* Addresses. If the addresses are filtered to only "home" or a particular city, that collection does not represent **all** Addresses and should not be mapped to the `.addresses` relationship. By allowing `contains_eager` on that filtered view, it is very possible that another section of code will be utilizing the object and not knowing that .addresses is filtered. The filtered view is Addresses, but not User.addresses. I've probably wanted to do this myself in the past, but experience has really taught me that this should not be allowed. I'd be +1 on a feature that prevents `contains_eager` to be invoked on a relationship if it is filtered/joined differently - though that would be immensely hard to detect on complex joins and likely not worth the effort. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/d89515ae-ea7b-44ca-b8c7-e1782a0801e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
