On Oct 2, 2012, at 6:28 AM, Vlad K. wrote: > On 10/01/2012 04:48 PM, Michael Bayer wrote: >> If I understand correctly, this isn't accurate. Your query needs the usage >> of query.join(), and this usage is not related to whether or not you supply >> a complete entity to select from. > > > I wasn't using explicit .join(), except an outerjoin on a one-to-one relation > with images table (which by default is lazyloaded). I thought SQLA would > figure it out itself based on foreign keys, as it usually does. Maybe that's > wrong, maybe I should be explicit, but so far it worked (when entire > instances of declarative_base were given to session.query()). > > I forgot to mention, and this could be the cause of perceived problems, that > I was listing columns of more than one model in the session.query(). Maybe > that confused it. > > What happened was that the query returned a list of named tuples for each of > the rows returned by the database, while I was expecting only one instance of > the main model (see below). > > >> I'm not sure what "won't automatically process inner joins" means, does that >> mean, you get an error message, or you're forced to call .join() as opposed >> to some other system of joining two entites, or what. > > I mean the cartesian cross-product in queries with many-to-many relations. > SQLA would "automatically" recognize the queried models and construct the > model instances and their relationships properly. > > E.g. if I query for single model that has X related in a many-to-many > fashion, the query would return X number of rows, like with .joinedload(), > but SQLA would return only one instance of the model, and its related > property filled with a list of X instances of that model, i.e it would > automatically process the joins and create a relationship tree in the session. > > I hope I'm making sense here. :) > > I guess I should make a minimal example case for this, and will do as time > permits.
I have a hunch what you're doing here. There is no "automatic" recognition of queried models and rendering of joins based on that, with the exception of joined eager loading which is something different. What there is, is that if you query for whole entities only, the Query will *de-duplicate* entries as rows are received. This is also so that strategies like joined eager loading allow the lead entry to be returned uniquely. So that would mean, you're getting many, many duplicate rows due to plain cartesian product, and the deduping of entities is hiding it. turn on echo='debug' on your create_engine() to see what's going on, then you'd probably want to start using join() to get the actual SQL you're looking for. -- 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.
