- changed title to customizable polymorphic_on/polymorphic_identity schemes
customizable polymorphic_on/polymorphic_identity schemes
The orm/inheritance/abc_inheritance
test relies upon fold_equivalents
to spell out a UNION which builds a polymorphic discriminator column on the fly. This whole use case (i.e., joined table inheritance with no discriminator column) is more easily managed by using regular joined table inheritance, joining to all tables (i.e. with_polymorphic), and using a callable polymorphic_on
function which checks for the presence of each joined table in order to determine the type. This is an easy enhancement and makes us compatible with Hibernate's joined table inheritance behavior. the whole fold_equivalents
feature which nobody is using anyway can then be removed won't be needed in this case (a nicer fold_equivalents proposed in #1729).
Comments (8)
-
reporter -
reporter bump
-
Account Deleted There are still use cases for the folded_equivalents function. see http://groups.google.com/group/sqlalchemy/browse_thread/thread/e008c06e55ee5e4 and does it really replace the folded_equivalents option used as keyword for joins?
-
reporter as mentioned in the email we'd like to move "fold_equivalents" into select() itself. I have added
#1729for that. -
reporter See
#2227illustrating howcolumn_property()
against any SQL expression can be used right now for some schemes. -
reporter current proposal: pass a callable to polymorphic_on():
polymorphic_on=fn
row, as well as the adapted row, is passed.
-
reporter - changed status to duplicate
superceded by
#2238 -
reporter - changed milestone to 1.x.xx
- Log in to comment
My current thinking is that this should be in a MapperExtension:
to support non-discriminator use cases:
When this is used,
polymorphic_on
is not set. The mapper will not auto-populate any discriminator column. that again is up to the user: