Michael Bayer wrote: > that doesnt sound right. taking out select_table, and doing: > > print > Media > .query > .select_from > (media_table > .join > (catalog_table > ).join > (catalog_channel_table > )).filter(CatalogChannel.c.id_channel==playlist.id_channel).all() > > leads to the SQL: > > SELECT medias.id AS medias_id, medias.name AS medias_name, > medias.id_catalog AS medias_id_catalog > FROM medias JOIN catalogs ON catalogs.id = medias.id_catalog JOIN > catalog_channels ON catalogs.id = catalog_channels.id > WHERE catalog_channels.id_channel = ? ORDER BY medias.oid > > which is entirely acceptable (and works in mysql).
Okay, my fault. I was editing the wrong code in my test case concerning the "select_from" alternative. Let's go back to that new feature from r4060 you've proposed, concerning joins directly from classes. Attached is my updated test case. If I wanted to join only from classes, I'd suppose we'd have the following syntax: Media.query.join([Media.catalog, CatalogChannel.id, CatalogChannel.channel]).filter(CatalogChannel.c.id_channel==playlist.id_channel).all() This would mean join Media on Catalog, join CatalogChannel on Catalog, join CatalogChannel on Channel; WHERE CatalogChannel.c.id_channel==foo. This is just an idea, but here the join with "CatalogChannel.id" would mean that is need to figure out that PK is also FK to Catalog. Regards, -- Alexandre CONRAD --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
SA_joined_inherited_class.py
Description: application/python
