some SQL constraint statements commented out in generated sql

[railk]

To Reproduce

Set up a django project and app, and set up an appropriate database. Put the following code in the app's models.py:

from django.db import models

class A(models.Model):
    b_ref = models.ForeignKey('B')

class B(models.Model):
    a_ref = models.ForeignKey(A)

Then run python manage.py sql <appname>

Output

BEGIN;
CREATE TABLE `testapp_a` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `b_ref_id` integer NOT NULL
)
;
CREATE TABLE `testapp_b` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `a_ref_id` integer NOT NULL
)
;
ALTER TABLE `testapp_a` ADD CONSTRAINT b_ref_id_refs_id_2727239a FOREIGN KEY (`b_ref_id`) REFERENCES `testapp_b` (`id`);
-- The following references should be added but depend on non-existent tables:
-- ALTER TABLE `testapp_b` ADD CONSTRAINT a_ref_id_refs_id_3bce8de8 FOREIGN KEY (`a_ref_id`) REFERENCES `testapp_a` (`id`);
COMMIT;

Expected Output

Same as output except that the last ALTER TABLE statement should not be commented out.

Patch

I have made a patch, but my python is a bit rusty...

[railk]

fix for commented-out constraints. my python is rusty, so may need cleanup.

[Ramiro Morales]

Which database engine/backend are you using?. See #4193

[railk]

It's not the backend, it's the circular referencing; Previously, when a model was processed in django.core.management.sql.sql_create, only pending references with this current model as the reference target where processed. The patch modifies sql_for_pending_references so it processed all references where the current model is the target *and* all references where the target is a known model and the reference's source is the current model... did that make any sense?

But to answer your question, I'm using MySQL.

[Ramiro Morales]

Duplicate of #4193