KBClassVisibility orphans not deleted when Workspace is deleted

[GoogleCodeExporter]

*What steps will reproduce the problem?*
1. Setup multiple workspaces and classes.
2. Delete a workspace.

*What is the expected output? What do you see instead?*

This causes a 500 error "'NoneType' object has no attribute 'id'" at 
/api/workspace/11/kb/class/

It is because the KBClassVisibility.workspace is now None instead of the 
KBClassVisibility object being deleted.

*What version of the product are you using? On what operating system?*

Latest checkout of notredam-replacement branch. Cent OS 6.

*Please provide any additional information below.*

I looked at the sqlalchemy documentation for the cascade option 
(http://docs.sqlalchemy.org/en/rel_0_8/orm/relationships.html#relationships-api)
 but it looks like is already setup correctly? I tried changing it to delete 
instead of delete-orphan, but still have the same issue. So I'm not sure if 
this is a SQLAlchemy bug or if the mapper's aren't quite setup right?

I also found this stackoverflow answer, which might be useful: 
http://stackoverflow.com/a/5034070/1316803

Original issue reported on code.google.com by jonat...@metaltoad.com on 10 May 2013 at 7:34

[GoogleCodeExporter]

It seems that this issue cannot be reproduced when using MySQL InnoDB tables, 
since they directly support SQL cascading clauses.  InnoDB is used by default 
on MySQL >= 5.5 (which can be found on the distribution we mainly support: 
Ubuntu 12.04).

I tried to revise the SQLAlchemy cascading options in order to better handle 
cascading on MyISAM tables (which are still used by default on MySQL 5.1.66, 
found on your CentOS 6).  However, I had no luck so far.

I think that I will add some hack to force InnoDB tables when the NotreDAM SQL 
schema is created.  Stay tuned for updates.

BTW: what version of SQLAlchemy are you using?

Original comment by alce...@crs4.it on 9 Jul 2013 at 3:27

• Changed state: Started

[GoogleCodeExporter]

I was using SQLAlchemy==0.8.0b2

Just updated to SQLAlchemy==0.8.2 and still have the same problem. You are 
right that the tables are MyISAM and not InnoDB.

Also, I tried altering the tables to InnoDB, but that did not help. I'm sure 
its because the foreign key constraints don't exist still. So I'm guessing the 
best way would be to dumpdata, drop the tables, set the default storage engine 
(https://docs.djangoproject.com/en/1.5/ref/databases/#creating-your-tables), 
syncdb then loaddata?

Original comment by jonat...@metaltoad.com on 10 Jul 2013 at 4:09