[Django] #28033: Allow passing choices as a callable in a model field
Django
-------------------------------------+-------------------------------------
Reporter: Ian Foote | Owner: nobody
Type: New | Status: new
feature |
Component: Database | Version: master
layer (models, ORM) |
Severity: Normal | Keywords: choices
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Currently
[https://docs.djangoproject.com/en/1.11/ref/models/fields/#choices
Field.choices] requires a fixed iterable, but this is not flexible for
choices that depend on information like the current date/time (eg I want
the next five years) or a value from {{{settings.py}}} which might change
between projects. Allowing a callable to be passed would allow the current
choices to be generated on demand and would avoid causing spurious
migrations when a setting is changed.
--
Ticket URL: <https://code.djangoproject.com/ticket/28033>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: Ian Foote | Owner: nobody
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Natim
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:2>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Rémy Hubscher):
1. How do we handle cases when the value in the database doesn't exists in
the callable iterator anymore.
- Let say you can select only a date during the next 7 days, how do
you update some other fields in the admin two weeks later?
2. What are the mandatory parameters that we need to provide to let the
callable be self sufficient on generating the callable?
- Probably the current instance? (We could handle a 7 days window
after the creation date of the object?)
Any thoughts about that?
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:3>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Rémy Hubscher):
Apparently changing the choices generate a migration, how should we handle
the migration with a callable? Should we ignore it in that case?
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:4>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Elena Neacsu):
As I understand, the only cases when we would need this as a callable is
when we would like to have something like this:
CHOOSE_DATE = [
("2017-04-05", "Yesterday"),
("2017-04-06", "Today"),
("2017-04-07", "Tomorrow"),
]
The dates should be updated every day to reflect the reality. So, it
concerns only the date/time, in other cases (e.g. categories or types) we
could just use a ForeignKey.
Could you confirm or provide some other cases?
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:5>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Elena Neacsu):
We might have an issue when it comes to displaying the list of choices,
lets say in Django admin; since the list could dynamically change it's
content the previous used values that do not exist in the list anymore,
won't be visible to the users.
Any suggestions on how we could tackle this?
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:6>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Marco Silva):
Would a outsourced list, (eg. from an api with a list of car brands or
person names) be a good use case to change the choice fields dynamicly?
I think the main problem here is what to do with stored data that is
currently "invalid"(present in the database but not in the returned list
from the callable), currently admin forms ignore it as if it was null
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:7>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Rémy Hubscher):
I wonder if appending the previous value as a valid value would be a good
enough solution.
i.e: It was valid at the time it was added so we could consider the
current value to be valid.
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:8>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Rémy Hubscher):
Work in progress in that branch:
https://github.com/Natim/django/pull/1/files
If you want to participate just ask me to add you as a Github collab on
that branch.
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:9>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by kapil garg):
From
[https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.Field.choices
django documentation]
"Note that choices can be any iterable object – not necessarily a list or
tuple. This lets you construct choices dynamically. "
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:10>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:11>
Django
-------------------------------------+-------------------------------------
| Hubscher
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Marco Silva):
Replying to [comment:10 kapil garg]:
> ''From
[https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.Field.choices
django documentation]
>
>
> "Note that choices can be any iterable object – not necessarily a list
or tuple. This lets you construct choices dynamically. "--''
>
> I see now what is missing.
>
When building the patch doc changes, I found that particular line to be
problematic, because it is folowed by "But if you find yourself hacking
choices to be dynamic", so, does it let you contruct choices dynamically,
or you have to hack choices?
The current patch is just a way to cleanly have any iterator class(that
can be used dynamicaly and provide the desired effect) be added on to the
migrations file with its class name and not as the calculated choices
list.
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:12>
Django
-------------------------------------+-------------------------------------
| Hubscher
Component: Database layer | Version: master
(models, ORM) |
Keywords: choices | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => duplicate
Comment:
Duplicate of #24561.
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:13>