#30741: sqlmigrate doesn't show a drop constraint SQL when previous create
constrain operation wasn't perform.
-------------------------------------+-------------------------------------
Reporter: Scott Stafford | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution:
| worksforme
Keywords: db_constraint, | Triage Stage:
migrations | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Scott Stafford):
Ah, yes, it appears the issue with introspection probably has to do with
our use of Postgres schemas. The table/constraint in question is in a
non-public schema
think I figured out what the issue is. In our setup, we use Postgres
schemas. When I set up the test example, I was lazy and used our existing
database and just let it create the tables right in there -- the new
`parent` table picked up the custom schema and that is somehow
interfering. When I retested after you said you couldn't repro, I made a
brand new database and then it worked as expected.
Would you still consider this a bug, or are we no longer "under warranty"
using schemas like this? If yes, I can try and set up a usable
reproduction project, and alter the title of the bug...
--
Ticket URL: <https://code.djangoproject.com/ticket/30741#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.09bde1c42ab44b4de4f2220a14416cec%40djangoproject.com.
