Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#2229 closed defect (wontfix)

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

Reported by: Owned by: adrian
Component: Core (Management commands) Version: master
Severity: minor Keywords: syncdb
Cc: simon@…, russellm, SmileyChris, ubernostrum 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 SmileyChris 9 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 9 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

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

  • Triage Stage changed from Unreviewed to Accepted

Changed 9 years ago by SmileyChris

comment:3 Changed 9 years ago by SmileyChris

  • Has patch set
  • Triage Stage changed from Accepted to Ready 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 9 years ago by russellm

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

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 8 years ago by Simon Litchfield <simon@…>

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 8 years ago by Simon Litchfield <simon@…>

  • Cc simon@… russellm SmileyChris added

comment:7 Changed 8 years ago by SmileyChris

  • Triage Stage changed from Ready for checkin to Design 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 8 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 8 years ago by Simon Litchfield <simon@…>

  • Cc ubernostrum 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