Opened 7 years ago

Closed 7 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: dev
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

Description

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.

Change History (13)

comment:1 by Markus Holtermann, 7 years ago

Triage Stage: UnreviewedAccepted

comment:2 by Rémy Hubscher, 7 years ago

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

comment:3 by Rémy Hubscher, 7 years ago

  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 by Rémy Hubscher, 7 years ago

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 by Elena Neacsu, 7 years ago

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?

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

comment:6 by Elena Neacsu, 7 years ago

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 by Marco Silva, 7 years ago

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 by Rémy Hubscher, 7 years ago

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 by Rémy Hubscher, 7 years ago

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.

comment:10 by kapil garg, 7 years ago

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.

Last edited 7 years ago by kapil garg (previous) (diff)

comment:11 by Marco Silva, 7 years ago

Has patch: set

in reply to:  10 comment:12 by Marco Silva, 7 years ago

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 by Mariusz Felisiak, 7 years ago

Resolution: duplicate
Status: assignedclosed

Duplicate of #24561.

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