#21454: Ignoring certain fields on INSERT and UPDATE queries
-------------------------------------+-------------------------------------
Reporter: mpessas | Owner: mpessas
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by mpessas):
Replying to [comment:2 akaariai]:
> It would be really useful to do autorefresh after save. Access to
database set values could also be done with RETURNING, but for first
implementation just executing a query from .save() would be enough.
I would rather avoid the extra query to re-read the db-default values; it
would have a significant impact on performance, when one of the goals was
to improve performance in the first place.
Regarding the `RETURNING` clause, it is not part of the SQL standard AFAIK
(see http://www.postgresql.org/docs/9.1/static/sql-update.html#AEN76402)
and that's the reason I avoided it. That said, can we have backend-
specific codepaths in Django? That is, use the `RETURNING` clause, when
available, and fallback to a re-read query otherwise.
In any case, I suppose we should allow the developer to skip the re-read
query, if using the `RETURNING` clause is not possible. How does that
sound?
>
> Validation code is needed to check that primary keys aren't
use_on_insert/use_on_update.
>
Done at
https://github.com/mpessas/django/commit/eda1b860311496d37bd6609b710f69fa4ae6fc41.
> Should there be a way to override the database assignment? How about
.update(modified_field=somevalue)? The simplest solution seems to be to
not allow override in .save(), but allow .update() of db default fields
Yes, that was my idea as well. The `.update()` method works as expected
(see
https://github.com/mpessas/django/commit/4fcfed999e82b08182b6c614553e7d707fdf4a6d).
>
> Fixtures loading should probably force-insert/update the fixture's
value, not use database default. This is doable by checking that if
raw=True in save, then insert everything as-is and don't do auto-update.
>
Fixed at
https://github.com/mpessas/django/commit/7540af0471346d62e60f1c61c27638b3233d4d5b.
However, I am not familiar with the process and as a result confident with
the commit; are we sure that the `raw` flag is used only for fixture
loading? Should I research a bit more?
> In addition, you will need also ModelForms support.
>
I suppose you mean that the fields should be excluded by default in
ModelForms.
I can think of three ways to do it:
- Do it in `fields_for_model`, that is, exclude all
`use_on_insert`/`use_on_update` fields, unless they are explicitly
included in the `fields` variable of the form. The big issue here is that
you cannot tell, whether the form will be used to ''create'' or ''update''
a row in order to handle `use_on_insert` and `use_on_update` fields
differently; you have to exclude both. See commit
https://github.com/mpessas/django/commit/3d298a6f269e28aa77e290aa4299cb17e3a6185b.
- Do it in the form's initializer. In this case, you do have access to the
`instance` variable; thus, you can tell whether the form is going to
''create'' or ''update'' a row. But this would not be consistent; the
developer would get a different set of fields in the two cases. Moreover,
the field selection process is part of the metaclass; as a result, the
code to exclude the db-default fields belongs to the metaclass as well.
- Do it in the `__call__` method of the metaclass. This keeps all field-
selection code in the metaclass, but still has the problem of consistency.
I am not sure which choice is best. The first one seems simpler to me
(from the point of view of the user of a ModelForm), since it avoids the
inconsistency issue (which would also leak to templates etc). Any opinions
here?
> In general I see this feature as useful when you need it, so marking as
accepted.
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/21454#comment:3>
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/065.8813e45826389e107347ef4a2d129b7b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
