Opened 3 years ago

Closed 3 years ago

#28033 closed New feature (duplicate)

Allow passing choices as a callable in a model field

Reported by: Ian Foote Owned by: Rémy Hubscher
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: choices
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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

Change History (13)

comment:1 Changed 3 years ago by Markus Holtermann

Triage Stage: UnreviewedAccepted

comment:2 Changed 3 years ago by Rémy Hubscher

Owner: changed from nobody to Rémy Hubscher
Status: newassigned

comment:3 Changed 3 years ago 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?
  1. 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?

comment:4 Changed 3 years ago 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?

comment:5 Changed 3 years ago 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:

    ("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?

Last edited 3 years ago by Rémy Hubscher (previous) (diff)

comment:6 Changed 3 years ago 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?

comment:7 Changed 3 years ago 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

comment:8 Changed 3 years ago 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.

comment:9 Changed 3 years ago by Rémy Hubscher

Work in progress in that branch:
If you want to participate just ask me to add you as a Github collab on that branch.

comment:10 Changed 3 years ago by kapil garg

Version 1, edited 3 years ago by kapil garg (previous) (next) (diff)

comment:11 Changed 3 years ago by Marco Silva

Has patch: set

comment:12 in reply to:  10 Changed 3 years ago by 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.

comment:13 Changed 3 years ago by felixxm

Resolution: duplicate
Status: assignedclosed

Duplicate of #24561.

Note: See TracTickets for help on using tickets.
Back to Top