> The way I'd want to add "polymorphic_on as a callable" would allow > one to replace the entire mechanism of the "discriminator", such > that there's not even a specific column that SQLA knows about in > that regard. This is a moderate change to the mapper internals, > but the big behavioral change is that the *population* of the > column would also become something you'd have to do on your end, > and I'd also have to figure out what its behavior with regards to > querying becomes - it would probably be several functions the user > needs to implement. just to remind, once u said that the get_primary_key mechanism can also be a user-provided piece... is this on the future-list?
--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---