--
Ticket URL: <https://code.djangoproject.com/ticket/28033>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:1>
* owner: nobody => Natim
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:2>
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>
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>
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>
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>
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>
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>
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>
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>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:11>
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>
* status: assigned => closed
* resolution: => duplicate
Comment:
Duplicate of #24561.
--
Ticket URL: <https://code.djangoproject.com/ticket/28033#comment:13>