#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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.09bde1c42ab44b4de4f2220a14416cec%40djangoproject.com.
