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

Reply via email to