Opened 9 years ago

Closed 8 years ago

#3549 closed (duplicate)

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

Reported by: phil.h.smith@… Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Keywords: GenericRelation reset sqlreset ./
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


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 ./ reset game will generate an extra DROP TABLE app_Y for each GenericRelation.

I believe the cause is in, 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.

Attachments (1)

3549.diff (798 bytes) - added by jaran 9 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 9 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Changed 9 years ago by jaran

comment:2 Changed 9 years ago by jaran

  • Has patch set

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?

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by durdinator

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #3480

Note: See TracTickets for help on using tickets.
Back to Top