#30108: Include FK constraints when adding columns in PostgreSQL
--------------------------------------+------------------------------------
Reporter: Dan Tao | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Dan Tao):
To summarize I think it's a great addition for AddField (and probably
AlterField?) but it's likely not worth the complexity it would incur for
CreateModel.
I think we're agreed on this. The benefit for CreateModel is negligible,
especially compared to the complexity of the refactor that would be
necessary to support it.
mainly around adding support for MySQL and Oracle
I am happy to do this. My only concern is that I am nowhere near an expert
in either of these databases (not that I am an expert in PostgreSQL,
either, but everything's relative!). From a cursory investigation, it
seems that [https://stackoverflow.com/a/1545264/105570 the MySQL syntax
for doing this] is a bit different and involves basically combining two
statements (an `ADD COLUMN` and an `ADD CONSTRAINT`) with a comma. The
[https://stackoverflow.com/a/45168000/105570 Oracle syntax] seems quite
similar to the PostgreSQL syntax.
Both the MySQL and the Oracle versions require that you specify a name for
the constraint, whereas it appears PostgreSQL handles that automatically.
Passing this along in the base schema editor will require a bit more
refactoring, though it looks very doable.
I'll do my best, and then we'll see how you feel about how things turn
out. I'm wondering, in the event we run into further complications with
MySQL and/or Oracle (for example, if you are not happy with the way I
refactor the code to support them), if you'd be opposed to deferring those
backends for now so that someone with more expertise in them can
contribute the necessary changes? Perhaps this will be moot—I'm just
preparing for the worst :)
And one more thing: would you prefer that we strive to keep the majority
of the discussion here on the ticket, or in the pull request? I'm assuming
we should keep it mostly here aside from comments that are specific to
details of the code; but if I've got that backwards I'm happy to continue
the discussion on the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/30108#comment:4>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/062.941089ff4768bf5083aaa5ae09c4d0c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
