Allow passing choices as a callable in a model field

[Ian Foote]

Currently ​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.

[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?

[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?

[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?

[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?

[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

[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.

[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.

[kapil garg]

From ​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.

[Marco Silva]

Replying to kapil garg:

From ​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.

[Mariusz Felisiak]

Duplicate of #24561.