[Django] #22611: sqlclear command tries to drop non-existing constraint with ForeignKey to self (postgresql)
Django
self (postgresql)
--------------------------------------------+------------------------
Reporter: valberg | Owner: nobody
Type: Bug | Status: new
Component: Core (Management commands) | Version: 1.7-beta-2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------------+------------------------
Having the following model (in an app called test_app):
{{{
class Foo(models.Model):
bar = models.ForeignKey('self')
}}}
The `sqlclear` management command returns:
{{{
$ ./manage.py sqlclear testapp
BEGIN;
ALTER TABLE "testapp_foo" DROP CONSTRAINT "bar_id_refs_id_83e148c5";
DROP TABLE "testapp_foo";
COMMIT;
}}}
Piping this into `psql` results in the following error:
{{{
> ./manage.py sqlclear testapp | psql -U django -h localhost django
BEGIN
ERROR: constraint "bar_id_refs_id_83e148c5" of relation "testapp_foo"
does not exist
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ROLLBACK
}}}
Checking the table in `psql` reveals:
{{{
django=# \d testapp_foo
Table "public.testapp_foo"
Column | Type | Modifiers
--------+---------+----------------------------------------------------------
id | integer | not null default
nextval('testapp_foo_id_seq'::regclass)
bar_id | integer | not null
Indexes:
"testapp_foo_pkey" PRIMARY KEY, btree (id)
"testapp_foo_bar_id" btree (bar_id)
Foreign-key constraints:
"testapp_foo_bar_id_fkey" FOREIGN KEY (bar_id) REFERENCES
testapp_foo(id) DEFERRABLE INITIALLY DEFERRED
Referenced by:
TABLE "testapp_foo" CONSTRAINT "testapp_foo_bar_id_fkey" FOREIGN KEY
(bar_id) REFERENCES testapp_foo(id) DEFERRABLE INITIALLY DEFERRED
}}}
So it seems that the `sqlclear` command generates a different name for the
constraint than it actually is. I'm guessing that postgresql is in charge
of
naming the constraint. At least looking at the output of the `sqlall`
command, there
is no indication of Django doing any naming.
{{{
$ ./manage.py sqlall testapp
BEGIN;
CREATE TABLE "testapp_foo" (
"id" serial NOT NULL PRIMARY KEY,
"bar_id" integer NOT NULL REFERENCES "testapp_foo" ("id") DEFERRABLE
INITIALLY DEFERRED
)
;
CREATE INDEX "testapp_foo_bar_id" ON "testapp_foo" ("bar_id");
COMMIT;
}}}
I've figured out that the "wrongful" naming is done in
`django.db.backends.creation.BaseDatabaseCreation.sql_remove_table_constraints`,
but there my knowledge of Djangos ORM stops :)
It might be worth noting that doing a simple DROP statement drops the
table
just fine. So maybe the ALTER statement isn't necessary?:
{{{
$ echo 'BEGIN; DROP TABLE "testapp_foo"; COMMIT;' | psql -U django -h
localhost django
BEGIN
DROP TABLE
COMMIT
}}}
(I'm using Django 1.7b3 installed with `pip install
git+https://github.com/django/django@stable/1.7.x#egg=Django`, but it is
not listed in the version list.)
--
Ticket URL: <https://code.djangoproject.com/ticket/22611>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
self (postgresql)
Reporter: valberg | Owner: nobody
Type: Bug | Status: new
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* needs_better_patch: => 0
* stage: Unreviewed => Accepted
* needs_tests: => 0
* needs_docs: => 0
Comment:
I can confirm this bug, I've encountered it while working on #19750.
However, the future of 'sql*' management commands is a bit uncertain with
the new migration framework. At least, they will need to be updated to use
the new `DatabaseSchemaEditor` classes.
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:1>
Django
self (postgresql)
Reporter: valberg | Owner: olethanh
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by olethanh):
* status: new => assigned
* owner: nobody => olethanh
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:2>
Django
self (postgresql)
Reporter: valberg | Owner: olethanh
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by valberg):
olethanh: How far are you with this?
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:3>
Django
self (postgresql)
Reporter: valberg | Owner: valberg
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by valberg):
* owner: olethanh => valberg
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:4>
Django
self (postgresql)
Reporter: valberg | Owner: valberg
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by valberg):
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
Comment:
I've made a pull request (https://github.com/django/django/pull/2659) and
would appreciate any feedback. I'm uncertain on a couple of topics:
- The `schema_editor.create_model()` takes care of creating indexes, so
`sql_indexes()` is not that straight forward to convert to using schema
editor.
- The old sql functions took the `style` argument, but this is not used
anywhere in the schema editor.
- The tests pass, but they probably need more improvement.
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:5>
Django
self (postgresql)
Reporter: valberg | Owner: valberg
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by andrewgodwin):
* severity: Normal => Release blocker
Comment:
I'd actually like to drop the sql* commands for apps that are marked as
having migrations, as they're no longer needed, and we'll finally
deprecate and remove them along with other creation-based stuff in 2.0
(they should pretty much be replaced by sqlmigrate, which obviously stays)
In particular, I think that:
* sql
* sqlall
* sqlcustom
* sqlindexes
* sqldropindexes
* sqlsequencereset
should be modified to error and quit if supplied with an app that's got
migrations. This would leave just `sqlflush` and `sqlmigrate` working for
those apps, which both make sense in the context.
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:6>
Django
self (postgresql)
Reporter: valberg | Owner: valberg
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by valberg):
I have made a new PR (now following the contribution guidelines):
https://github.com/django/django/pull/2742
There are still some issues with coloring though. I will address that if
the rest of the PR looks good.
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:7>
Django
self (postgresql)
Reporter: valberg | Owner: valberg
Type: Bug | Status: assigned
Component: Core (Management | Version:
commands) | 1.7-beta-2
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Changes (by andrewgodwin):
* severity: Release blocker => Normal
Comment:
valberg has just confirmed on IRC that this is also a problem on 1.6, so
as it's no longer a regression, dropping release blocker status.
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:8>
Django
self (postgresql)
Reporter: valberg | Owner:
Type: Bug | Status: new
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by valberg):
* status: assigned => new
* needs_better_patch: 1 => 0
* has_patch: 1 => 0
* owner: valberg =>
Comment:
Since this is an old bug, and the sql commands are likely to go away in
future versions due to migrations, I'm stopping the work on this.
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:9>
Django
self (postgresql)
Reporter: valberg | Owner:
Type: Bug | Status: new
Component: Core (Management | Version:
commands) | 1.7-beta-2
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
#22910 was a duplicate (related to sqldropindexes)
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:10>
Django
self (postgresql)
Reporter: valberg | Owner:
Type: Bug | Status: closed
Component: Core (Management | Version:
commands) | 1.7-beta-2
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/22611#comment:11>