We've fixed this by adding the column to the database and mapping the parent class to a plain table again... However if this is something that you think is worth fixing here are some illustrative differences:
This is what mapper.polymorphic_iterator() looks like for the normally multi table inheritance case: (I've replaced the __repr__ of Table to just return the table name for illustrative purposes) In [18]: [map.tables for map in m.instrument_map.polymorphic_iterator ()] Out[18]: [[instrument], [instrument, future], [instrument, fx_option], [instrument, fx_fwd], [instrument, yield], [instrument, equity], [instrument, lme_fwd], [instrument, cash]] This is what it looks like with when the parent model is mapped to a select: In [17]: [map.tables for map in m.holiday_map.polymorphic_iterator()] Out[17]: [[holiday, holiday, holiday_country_map, holiday_exchange_map, holiday_instrument_map, holiday, holiday, holiday], [holiday_country_map, holiday, holiday, holiday_country_map, holiday_exchange_map, holiday_instrument_map, holiday, holiday, holiday], [holiday_instrument_map, holiday, holiday, holiday_country_map, holiday_exchange_map, holiday_instrument_map, holiday, holiday, holiday], [holiday_exchange_map, holiday, holiday, holiday_country_map, holiday_exchange_map, holiday_instrument_map, holiday, holiday, holiday]] And this is what the mapper for one of the child classes gives for its tables: In [3]: m.holiday_instrument_map.tables Out[3]: [holiday_instrument_map, holiday, holiday, holiday_country_map, holiday_exchange_map, holiday_instrument_map, holiday, holiday, holiday] This would lead me to believe that somewhere in _sorted_tables or polymorphic_iterator by something in the mapping I had before. Hope this helps! Ben On 14 Dec, 17:45, "Michael Bayer" <[email protected]> wrote: > boothead wrote: > > Hi, > > > I have a parent/superclass object in a polymorphic relationship which > > is mapped against a select. The select is a table and a coalesce > > function (the coalesce is to make up for the fact that the > > polymorphic_on column doesn't exist). > > > All seems to be working fine on update, create etc but delete is > > coming a cropper here: > > > /sqlalchemy/orm/mapper.pyc in _delete_obj(self, states, > > uowtransaction) > > 1459 mapper = table_to_mapper[table] > > 1460 clause = sql.and_() > > -> 1461 for col in mapper._pks_by_table[table]: > > 1462 clause.clauses.append(col == sql.bindparam > > (col.key, type_=col.type)) > > 1463 if mapper.version_id_col and > > table.c.contains_column(mapper.version_id_col): > > > KeyError: Table('map_table', MetaData > > (<sqlalchemy.engine.base.Connection object at 0x8751210>), Column > > (...), ....) > > what version sqla you're on ? The line numbers aren't ordered that way > in 0.5.6. The dict lookup there should not be reachable as there's a > check for column present in the pks dict up above that would prevent the > delete collection from being populated. That code definitely needs a > little adjustment as its looping unnecessarily but still should be working > the way it is. > > > > > In this instance map_table (names changed to protect the guilty) is > > our child table and I've just done: > > > In [32]: q = ses.query(ChildClass) > > > In [33]: h = q[0] > > > In [34]: ses.delete(h) > > > In [35]: ses.flush() > > > At which point "kaboom". > > > Interestingly the 'mapper' in question in the traceback is the mapper > > for a different child class i.e. NOT ChildClass in the ipython > > example above, but 'table' is the the table mapped to ChildClass. > > > There are three of these child tables, all configured the same way and > > one of them actually works for deleting. The one type of child class > > that I can delete also belongs mapper in question when I get the above > > traceback when trying to delete instances of the other two children. I > > don't know if that's significant or not? > > > The only columns in the map_table are a foreign key to the parent > > table / superclass and a foreign key to a related object (which are a > > composite primary key) and an additional column. > > > I'm pretty sure that I'm doing something nasty, but the only really > > out of the ordinary thing (as compared with the documentation) is that > > the super class is mapped to something like: > > > my_super_table = select([superclass_table, func.coalesce > > (<some_stuff>)]).alias('my_superclass_table') > > > This is the gist of the SQL that > > >>>> print select(my_super_table) > > > gives: > > > SELECT my_super_table.col1 ... > > FROM > > (SELECT h.col1 ..., > > coalesce( > > (SELECT 'C' FROM child1_map > > WHERE child1_map.holiday_id = h.holiday_id), > > (SELECT 'E' FROM dots.child2_map > > WHERE child2_map.holiday_id = h.holiday_id), > > (SELECT 'I' FROM child3_map > > WHERE child1_map.holiday_id = h.holiday_id) > > ) AS my_polymorphic_column > > FROM the_old_table h) my_super_table > > > This is the sql I want, and as I mentioned update and select seems to > > be fine > > > So, is this a problem with incorrectly configuring cascade rules, or > > have I found a corner case that should work but doesn't..? > > > Cheers, > > Ben > > > -- > > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to [email protected]. > > 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. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
