[Django] #27222: Refresh expressions on save
Django
----------------------------------------------+--------------------
Reporter: holvianssi | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
The use case is automatically fetching the value for expressions when
saving to DB. For example:
{{{
> user = User.objects.create(username=Lower('Anssi'))
> user.username == 'anssi'
True
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27222>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: holvianssi | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by holvianssi):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
> The use case is automatically fetching the value for expressions when
> saving to DB. For example:
> {{{
> > user = User.objects.create(username=Lower('Anssi'))
> > user.username == 'anssi'
> True
> }}}
New description:
The use case is automatically fetching the value for expressions when
saving to DB. For example:
{{{
> user = User.objects.create(username=Lower('Anssi'))
> user.username == 'anssi'
True
}}}
While the above feature can be simulated somewhat easily by calling
refresh_from_db() after save, an in-built implementation has the ability
to use RETURNING as an optimization. In addition, it seems that refreshing
objects on save would be a nice default, though this might be a bit
backwards incompatible in some cases.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: holvianssi | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* stage: Unreviewed => Accepted
Comment:
Does this also fix #23386? In that case, we might close this as a
duplicate.
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:2>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/7244 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:3>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by charettes):
This might also be related to #21454 or at least to the implementation
proposed in it's [https://github.com/django/django/pull/5904 PR] as we
should really be using `RETURNING` on backends that support it instead of
performing a second `SELECT` to fetch the database generated fields.
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:4>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by holvianssi):
I'm hesitant to go with RETURNING implementation for the first patch. The
select approach is really simple, and it will be needed in any case for
some backends. The RETURNING approach on the other hand will be complex,
and after all it's just an optimisation.
This should almost solve #21454 with a Default expression. This would need
to be assigned manually to fields pre-save. Then full solution to #21454
would be adding a bit of API to do the pre-save assignments automatically.
And yes, I believe this solves #23386.
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:5>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: 0 => 1
Comment:
Comments for improvement on the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:6>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* needs_better_patch: 1 => 0
Comment:
I update the PR per my comments.
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:7>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* needs_better_patch: 0 => 1
Comment:
Simon still has concerns described on the pull request.
--
Ticket URL: <https://code.djangoproject.com/ticket/27222#comment:8>