Models that use GenericRelation generate multiple drop statements in ./manage.sql reset app

[phil.h.smith@…]

If a model X explicitly defines a GenericRelation to act as the reverse end of a GenericForeignKey from model Y, then the sql generated by ./manage.py reset game will generate an extra DROP TABLE app_Y for each GenericRelation.

I believe the cause is in django.core.management.get_sql_delete, in the many-to-many section around line 307 or so. Model X apparently treats a GenericRelation(Y) as a ManyToManyField(Y) here. This might be appropriate (I don't know), but either way collecting these tables in the set() created above would uniquefy them and solve the issue.

[jaran]

Added simple patch that adds a check to make sure the drop statement is unique. This solves the problems i have been running into with generic relations and reset app although there might be a better way to patch this?

[jpd <jd@…>]

#3480 has the same root problem. Patch there which may solve the dupe DROP issue a bit more safely than the one here.

[durdinator]

Duplicate of #3480