QuerySet.delete() attempts to delete unmanaged models.

Hrm, this will require some thought, as an unmanaged model *could* indicate something like a db view that you can't delete from, however that semantic is in no way implied by the documentation.

I would say that the proper way to handle this would be to have a kwarg for the delete method. QuerySet?.delete(cascade=False) Seems reasonable, at least.

Urgh. This is messy. The idea in comment:3 isn't a solution, since this isn't a property of the delete() call -- it's a property of the model definition (and cascading delete behaviour is the subject of another ticket and unresolved as yet because it's a hard problem to cover all use-cases). The current behaviour is correct (unmanaged refers to syncdb and other SQL-altering statements), but we should be able to handle Justin's case, too.

Would be nice to have a solution for 1.1, so I'll give this some thought.

For any looking for a stop-gap, I've gotten past it by writing a delete() method which invalidates the FK used to populate my view which then allows it to delete cleanly. Code is:

    def delete(self):
        baseid = self.baseobject_ptr_id
        BaseRelation.objects.filter(models.Q(base_obj=baseid) | models.Q(related_obj=baseid)).delete()
        super(Video, self).delete()

This is probably a subset of the "deletes always cascade" bug, but even if not this won't be fixed in the 1.1 timeframe.

This is a show stopper for us so I have a small patch

line 1002 django\db\models\query.py

perform_delete = True

if cls._meta.managed == False:
    check_view = "select count(TABLE_NAME) from INFORMATION_SCHEMA.VIEWS WHERE TABLE_NAME = '%s';" % cls._meta.db_table
    cursor = connection.cursor()
    cursor.execute(check_view, [])
    if not cursor.rowcount == 0:
        perform_delete = False
    
if perform_delete:
   ...... the rest of the deletion of code

It's ugly as hell I know but a start.

Patch for MySQL unmanaged view (discussed in comment#7)

Replying to Alex:

Hrm, this will require some thought, as an unmanaged model *could* indicate something like a db view that you can't delete from, however that semantic is in no way implied by the documentation.

I think that if you create a structure that can represent a view it's API should know how to deal with database changes operations. It's look like a bug to me.