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


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to