I touched on this in an earlier thread, but think it deserves its own.
The current inheritance implementation requires a column specified for
polymorphic_on passed to a mapper and a value for that column specified
for each inheriting mapper. I don't think this approach is flexible
enough and I think there are better ways to do this.
For discussion, consider the Employee, Manager, Engineer example from
the docs. If I were designing the tables, I would not normally have a
"type" field. I would use the null status of engineer_info or
manager_data to determine the employee type. Or if that data was in
separate tables, I would use the existence of records in those tables.
And these are simple cases. I can think of some real life cases where
the values of multiple fields would determine the class.
I think it would be good to have the same type of flexibility as mapping
a class to a select object. In fact, I'm wondering now if the two can
be used in combination to this effect. Maybe something like ...
Map to a select object that does this:
"SELECT employee_id, name, manager_data, engineer_info, 'engineer'
as type FROM employees WHERE engineer_info IS NOT NULL"
Do that for the manager too, and apply polymorphic inheritance.
That would allow for great flexibility without having duplicate type
information (type + engineer_info) in the table. I'm going to play with
this some more and am interested in what others think.
Randall
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
