[sqlalchemy] Re: polymorphic_identity determination

2006-11-08 Thread Michael Bayer
On Nov 8, 2006, at 12:04 AM, Randall Smith wrote: That leads to the part I'm stuck on; mapper inheritance. When finished, session.query(Employee).select() should list all employee as instances of their specific classes and session.query(Engineer).select() should list all engineers ...

[sqlalchemy] Re: polymorphic_identity determination

2006-11-07 Thread Randall Smith
I worked on this some more and found that the queries are correct as they are. The problem is in the mapping. A Chemical Engineer is an Engineer, who is an Employee. So the employees selectable should return all employees and the engineer selectable should return all engineers, not just

[sqlalchemy] Re: polymorphic_identity determination

2006-11-06 Thread Michael Bayer
hey, no, youre doing great, breaking new ground yourself. i havent spent much time with inheritance scenarios other than what you see in the examples and unittests (and a lot of that other people came up with). just as long as the rowsets contain the information, things are good. this is also

[sqlalchemy] Re: polymorphic_identity determination

2006-11-05 Thread Randall Smith
I've attached a file which is a variant to the employees example with two objectives. 1. Base polymorphic_identity on select criteria (no type column). 2. Use two levels of inheritance. The first objective seems to be met, but the second is not working properly. I put in two Managers, two

[sqlalchemy] Re: polymorphic_identity determination

2006-11-05 Thread Michael Bayer
if you change your echo to 'debug', or just select straight from your p_union selectable, youll see these rows: (5, u'cengineer1', u'cengineer1', u'cengineer1', None, u'chemical_engineer') (6, u'cengineer2', u'cengineer2', u'cengineer2', None, u'chemical_engineer') (1, u'manager1', None, None,

[sqlalchemy] Re: polymorphic_identity determination

2006-11-05 Thread John M Camara
Randall Smith wrote: 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

[sqlalchemy] Re: polymorphic_identity determination

2006-11-05 Thread Randall Smith
John, Thanks for the feedback. The code I put up is not part of any real system. I'm just playing off of the existing examples in the docs and trying to get comfortable with SA inheritance. Randall John M Camara wrote: Randall Smith wrote: For discussion, consider the Employee,

[sqlalchemy] Re: polymorphic_identity determination

2006-11-04 Thread Michael Bayer
just FYI, the type column idea is taken from Hibernate, and that's all Hibernate supports as far as polymorphic loading. But for polymorphic loading in SA, you are free to make any kind of polymorphic_union you like that can add in a functionally-generated type column, and specify it into

[sqlalchemy] Re: polymorphic_identity determination

2006-11-04 Thread Randall Smith
Michael Bayer wrote: just FYI, the type column idea is taken from Hibernate, and that's all Hibernate supports as far as polymorphic loading. I think it's good that SA takes good features from and is similar to Hibernate, but I hope that your aspirations and those of SA's users are to make