#29444 closed Cleanup/optimization (fixed)
Allow fields to be part of the RETURNING clause during INSERT
Description ¶
Dependency for #27452
The SQL RETURNING
statement is currently used for inserts of new objects. Mainly it is responsible to return the primary key in a single query.
That's great but currently in the postgres database backend this value is hard coded to only the primary key. I would like to propose to make this configurable.
There are plenty of uses cases for such a feature ultimately even enabling database defaults, but I would suggest to keep it very simple for now.
I would suggest to simply allow model fields to specify if they should be included in the returning statement or not. The default being not (except PK) to maintain the current behavior.
The implementation as well as the related code lines have been already discussed here:
https://github.com/django/django/pull/7525#issuecomment-354269077
I highly suggest to keep this a Postgres ONLY feature for now. That way we can see what sticks and consider extending this functionality into django.db
in the future after we have seen how it's being used and gathered feedback.
Change History (29)
comment:1 by , 7 years ago
Version: | 2.0 → master |
---|
comment:2 by , 7 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:4 by , 7 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:5 by , 7 years ago
Patch needs improvement: | unset |
---|
comment:6 by , 7 years ago
Patch needs improvement: | set |
---|
comment:7 by , 7 years ago
Patch needs improvement: | unset |
---|---|
Type: | New feature → Cleanup/optimization |
comment:8 by , 6 years ago
Component: | contrib.postgres → Database layer (models, ORM) |
---|---|
Patch needs improvement: | set |
Summary: | Allow modification of RETURNING values in django.contrib.postgres → Allow fields to be part of the RETURNING clause during INSERT |
A number of Oracle test failures remain.
comment:9 by , 6 years ago
Patch needs improvement: | unset |
---|
I fixed a couple of things. Nothing fails for me now locally that doesn't fail on master. Can you trigger it again?
comment:11 by , 6 years ago
Patch needs improvement: | set |
---|
You should be able to trigger the Oracle build yourself as described on wiki:Jenkins. I ran the tests locally and put the failures in a PR comment.
comment:12 by , 6 years ago
Patch needs improvement: | unset |
---|
comment:13 by , 6 years ago
Needs tests: | set |
---|
comment:14 by , 6 years ago
Needs tests: | unset |
---|
comment:15 by , 6 years ago
Patch needs improvement: | set |
---|
comment:16 by , 6 years ago
Patch needs improvement: | unset |
---|
comment:18 by , 6 years ago
Patch needs improvement: | set |
---|
comment:19 by , 6 years ago
Patch needs improvement: | unset |
---|
comment:21 by , 5 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
by , 5 years ago
Attachment: | refs-29444-oracle-part.diff added |
---|
comment:24 by , 5 years ago
Has patch: | unset |
---|---|
Triage Stage: | Ready for checkin → Accepted |
This ticket is doable on Oracle with cx_Oracle
6.0+ that's why I'm leaving it open. First attempt of fixing this on Oracle was a part of the original PR (see a diff).
comment:25 by , 5 years ago
Has patch: | set |
---|---|
Patch needs improvement: | set |
comment:26 by , 5 years ago
Patch needs improvement: | unset |
---|
PR