Well, there ought to be more Bravos and Congratulations on this thread. I only held back figuring others would pile on well enough. Or maybe most of the polymorphists out there are gleefully silent about what they're brewing up.
Thanks for the insight. Wish I'd thought of it earlier too. Funny, though; only three weeks after this came up, I'm replacing most of my more complicated uses of polymorphism with more of a 'vertical tables' approach. I'd likely be months behind where I am now if not for sqlalchemy. Thanks for all the tools. On Jun 8, 8:31 am, Michael Bayer <[EMAIL PROTECTED]> wrote: > I know ive put many folks through the wringer dealing with this > function, in order to get their inherited mappers to load instances > polymorphically. It seems like we probably dont need it for the most > common case, which is that you are using only joined-table > inheritance from a single common base table (i.e. no concrete- > inheritance), and have a specific column in your base table that > indicates the "polymorphic type". if thats the case, you can forego > the usage of polymorphic_union and just string together your tables > using joins and outerjoins. Theres a slight tweak in the post 0.3.8 > trunk with eager loading to get "eager loading to a polymorphic > mapper" to work with this case. > > meaning, you can make mappers like this: > > page_join = page_table.outerjoin(magazine_page_table).outerjoin > (classified_page_table) > magazine_join = page_table.join(magazine_page_table).outerjoin > (classified_page_table) > > page_mapper = mapper(Page, page_table, select_table=page_join, > polymorphic_on=page_table.c.type, polymorphic_identity='p') > > magazine_page_mapper = mapper(MagazinePage, magazine_page_table, > select_table=magazine_join, inherits=page_mapper, > polymorphic_identity='m') > > classified_page_mapper = mapper(ClassifiedPage, > classified_page_table, inherits=magazine_page_mapper, > polymorphic_identity='c') > > full example attached. > > conclusions we can draw from this ? I am really, really dumb for not > seeing this for like, the past year. the queries are a lot easier to > create and read, plus we avoid all the other issues UNIONS bring > forth (like same column name but different types colliding, etc). > > polymorphic.py > 1KDownload > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
