Re: How do you set choices in your application?

Hello,

I'm not legitimate to answer you but I'm adding other options that experienced people can comment.

I'd rather use a ForeignKey in that context but I don't have to think to much to performances in my apps. You can easily add status, handle i18n this way. I must confess that writing "data in hard" into the code itself makes me nervous too. This is a documented option so maybe some arguments we'll help to overcome this bias.

If performances are an issue, I think about caching and I'll go to your third solution with http://docs.djangoproject.com/en/dev/ref/models/querysets/#pickling-querysets with maybe some "caching" issues to deal with.

By the way, I'll add to Russel's comments that even if someone tries to answer you, this can be time consuming because this answer will be send to the community and it better be as correct as possible (both in social, formal and  technical domains) and that implies reviewing your answer. You can take also in consideration than for some people, english is not really flowing when their main mentor is exception.Exception.

Regards,

Le 25/09/2010 02:51, Yo-Yo Ma a écrit :

Let's say I have a model with a field called "status". I could set the choices in three ways:  1)   status_choices = ((1, 'Completed'), (2, 'Unfinished'), (3, 'Cancelled'))   2)  status_choices = (('COM', 'Completed'), ('UNF', 'Unfinished'), ('CAN', 'Cancelled'))   Or, 3 ):  db_choices = Choice.objects.all() status_choices = [[choice.pk, choice.description] for choice in db_choices]  Is there any best practice? Note: Client's won't be able to define these choices. They'll all be defined by me (or else DB would be the answer of course).  My thoughts:  1) Risky (data is useless without python file), 2) Slower, and risky because it might be difficult to change later, 3) a lot of work, and slow (because of DB).