remember that polymorphic_union function ?

[Michael Bayer]

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).

[sdo...@sistechnology.com]

> 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.

hah. is this completely replacing punion for the whole
table-inheritance-only case, or there are some holes?
i'll run my tests (yeah, those annoying thousands of combinations u
never liked :-) to see... and will report.
The concrete+polymorhic doesn't work anyway (db_id collision), and the
mixed concrete+multitable/polymorphic case accordingly.

> 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).

well, u have paid the bill - all those corresponding_column,
column_equivalents etc complications (and i run into those yesterday
again, trying to automate expression-generation over a polymorphic
base...)

==============

some questions arise around the example, trying to generalise it for
any levels:
- page_join and magazine_page_join are _same_; classifed has just its
table as localtable. Should this mean, that genericaly, leafs need
just their table, and all non-leafs need same outerjoins of the full
hierarchy (i.e. the root one)
- how u do a branch in the hierahcy? i.e. to have DocumentPage(page),
sibling to magazinePage?

cheers
svilen

[Eric Ongerth]

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.

> polymorphic.py
> 1KDownload
>
>

[svilen]

On Monday 02 July 2007 00:45:18 Eric Ongerth wrote:
> 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.

can u explain a bit to one of the "polymorhists" :-)
i mean, i dont give a shit if its polymunion or else, i just want my
class tree to go into sql and then get it back sanely.

so far i see that if i have inheritance A-B-C-D, this approach works;
but if i have A-B-C and B-D, or A-B-C and A-D-E, i can't see how.
or i am not understanding something?

ta
svil