Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#2229 closed defect (wontfix)

django-admin's syncdb does not check for missing many-to-many tables

Reported by: Owned by: Adrian Holovaty
Component: Core (Management commands) Version: master
Severity: minor Keywords: syncdb
Cc: simon@…, Russell Keith-Magee, Chris Beaven, James Bennett Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


' dyncdb' command does not check for out of missing many-to-many tables. That is if you remove any table, it would detect and create it, but it doesn't seem to check for django generated many-to-many tables that maybe missing.

Attachments (1)

m2m_syncdb.patch (5.3 KB) - added by Chris Beaven 10 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 10 years ago by (none)

milestone: Version 1.0

Milestone Version 1.0 deleted

comment:2 Changed 10 years ago by Gary Wilson <gary.wilson@…>

Triage Stage: UnreviewedAccepted

Changed 10 years ago by Chris Beaven

Attachment: m2m_syncdb.patch added

comment:3 Changed 10 years ago by Chris Beaven

Has patch: set
Triage Stage: AcceptedReady for checkin

I moved the main SQL code to a different function so it could be called for an individual field, then fixed syncdb to use this new function.

I also reckon there should be some printout at the default level of verbosity for the creation of m2m tables, but that's not what this ticket is about.

Bumping to ready to give it some visibility, bump back if something's wrong (it works for me).

comment:4 Changed 10 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

I'm inclined to reject this idea. Syncdb doesn't have any schema-evolution behaviour for data fields. Adding evolution-like behaviour for m2m fields could lead to problems where a user modifies a model, resync's, and gets *some* of their changes reflected in the database. My crystal ball forsees nightmare threads on django-users debugging these problems.

I feel the right solution here is to get schema-evolution working, and in the meantime, continuing the story of 'if you change your model, drop the database and resync'.

comment:5 Changed 9 years ago by Simon Litchfield <simon@…>

Resolution: wontfix
Status: closedreopened

Definitely in favour of syncdb creating missing m2m's, in the same way it creates missing base tables. Lets keep it consistent. No damage can possibly be done.

Usual workaround here, is to rename the affected tables, run syncdb, drop the new ones except the new m2m, then rename back again. Clumsy stuff.

Schema-evolution is exciting stuff but a different story to syncdb, at least in trunk for the forseeable future (v1.0 - correct me if I'm wrong?).

The obvious solution is to add m2m's to default verbosity, as Chris suggests, something like --

Creating m2m table reminders_reminder_rsvp_users

This keeps it plainly obvious that base tables aren't being touched. And why would they, we haven't given that impression anywhere?

comment:6 Changed 9 years ago by Simon Litchfield <simon@…>

Cc: simon@… Russell Keith-Magee Chris Beaven added

comment:7 Changed 9 years ago by Chris Beaven

Triage Stage: Ready for checkinDesign decision needed

I see both sides of the argument.

From a technical perspective, it's not touching existing sql so this change is fine.

From a philosophical perspective, it it adding a field to the model, so it's evolution territory.

Personally, it doesn't bother me too much now since I use django-evolution, but I can see this is still an issue for those who don't. It's not easy formulating the sql for this yourself and from the technical perspective, it's not going to damage any data. In any case, I'll move back to a design decision.

Simon, you should probably have just brought this up in django-dev rather than reopening though. Want to do that now please?

comment:8 Changed 9 years ago by James Bennett

Resolution: wontfix
Status: reopenedclosed

Russell's argument is as convincing now as it was originally; the idea that "well, syncdb will sometimes change your database layout when you add a field to a model, but sometimes won't" is just a nightmare waiting to happen.

comment:9 Changed 9 years ago by Simon Litchfield <simon@…>

Cc: James Bennett added

The flipside is: "well, syncdb will sometimes create your tables, sometimes not, and often create them without telling you (m2ms)". Hmmm.

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