Opened 13 years ago
Closed 13 years ago
#17465 closed New feature (wontfix)
Multiple INSERT RETURNING
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.4-alpha-1 |
Severity: | Normal | Keywords: | db, orm, insert, django models |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Postgresql/oracle support multiple returning on insert request, django doesn't.
A have table
CREATE TABLE db_table ( id integer NOT NULL, sid integer, oid integer NOT NULL, name1 character varying(250) NOT NULL, name1 text NOT NULL, );
and want to execute query:
INSERT INTO db_table (name1, name2) values ("value1", "value2") RETURNING id, sid, oid,
sid, oid values calculating by trigger before insert, and I need to use its after saving model.
Example of definition.
class DbTable(models.Model): oid = models.IntegerField(null=True, return=True) sid = models.IntegerField(null=True, return=True) name1 = modelsCharField(max_length=250) name2 = models.TextFiled()
or
class DbTable(models.Model): oid = models.IntegerField(null=True) sid = models.IntegerField(null=True) name1 = modelsCharField(max_length=250) name2 = models.TextFiled() class Meta: returning = ('oid', 'sid')
What do you think about whit feature?
Note:
See TracTickets
for help on using tickets.
As with all proposed feature additions, my question is Why?
What is the use case for this feature? Your example code shows a bunch of insertions of new objects -- why doesn't the basic Django pattern of just accessing the attribute of the object you just inserted work here?
Django's ORM doesn't currently expose the return value of INSERT calls -- they're returned implicitly. Why should Django's ORM provide access to INSERT return values? And given that you can access the inserted value using the attributes on the inserted object, why should we add a second way to access the inserted value?
Remember, Django's ORM isn't an attempt to be a 100% match for SQL syntax. It's an attempt to make a slightly more object-like layer around SQL syntax. If you have an esoteric use case, it's entirely possible that the fix lies in using SQL directly, rather than in trying to munge Django's ORM to be more SQL-like.
Marking wontfix, because no use case is provided, and while 2 syntaxes have been proposed, there's no explanation of how this maps onto actual usage in practice. If you want to defend this proposed feature, please take it up on the django-developers mailing list.