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

[TwistedCommons.com]

'django-admin.py 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.

[(none)]

Milestone Version 1.0 deleted

[Chris Beaven]

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).

[Russell Keith-Magee]

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'.

[Simon Litchfield <simon@…>]

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?

[Chris Beaven]

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?

[James Bennett]

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.

[Simon Litchfield <simon@…>]

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