boothead wrote:
> I'm on version 0.5.3, I will try it on 0.5.6 tomorrow.
>
> The check for column present above could be the problem... The column
> that I'm adding in the select is a func.coalesce(...).label
> ('something') and the my_super_table select that I'm mapping to is
> aliased... Would that throw off the "column in table" check?it just wants to find that the given table within the mapping has primary key columns represented in the mapping, so that it can do a delete. Its likely that there was a bug in earlier 0.5 versions regarding this as far as delete. > > Thanks for the speedy reply! > 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. > > > -- 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.
