How to handle model constants

[Frankline]

Hi all,

I am getting confused regarding the use of constants and would be keen to know how the rest of you handle constants in your models. Ofcourse I could handle it easily similar to how it has been handled here: https://docs.djangoproject.com/en/1.7/ref/models/fields/#django.db.models.Field.choices

But I wanted to put the constants in a separate class on their own. This is what I hav so far:

models.py

class TaskStatus(models.Model):

    CANCELLED = 0
    REQUIRES_ATTENTION = 1
    WORK_IN_PROGRESS = 2
    COMPLETE = 3

    STATUS_TYPES = (
        (CANCELLED, 'Cancelled'),
        (REQUIRES_ATTENTION, 'Requires attention'),
        (WORK_IN_PROGRESS, 'Work in progress'),
        (COMPLETE, 'Complete'),
    )

    status = models.IntegerField(choices=STATUS_TYPES, default=REQUIRES_ATTENTION)    
    
class Task(models.Model):
    status = models.ManyToManyField(TaskStatus, default=TaskStatus.REQUIRES_ATTENTION)

    

In my case, a Task can have one or more TaskStatus. I do not wish to store the TaskStatus in the database since they are simply constants.

Does anyone have a better way of how I can approach this?

[Thomas Rega]

Hi,

I do not know if this approach is better but I am using
https://pypi.python.org/pypi/django-enumfield/ for such kind of
fields.

Just my 2 cents

Good luck

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAEAUGdX-eGA9mY5h%2Bj0yDHeFe_cX%3DP_i0ToRjp%2BDbRsDGCPaDw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Mike Dewhirst]

On 23/02/2015 5:23 PM, Frankline wrote:
> Hi all,
>
> I am getting confused regarding the use of constants and would be keen to
> know how the rest of you handle constants in your models. Ofcourse I could
> handle it easily similar to how it has been handled here:
> https://docs.djangoproject.com/en/1.7/ref/models/fields/#django.db.models.Field.choices
>

I have many many constants which are used across a number of modules and
apps.

I store them in the __init__.py file of the namespace in which they are
used. Sensible naming of constants is vital of course and I'm careful to
store them alphabetically so I can find them easily enough scrolling
quickly through the file.

At the top of my modules I say ...

from <namespace> import CONST1, CONST2 etc

Works for me

Mike

[James Schneider]

For global constants, I would second the strategy that Mike outlined, and rename your constants in a more specific way, such as TASK_CANCELLED, TASK_COMPLETE, etc. unless of course CANCELLED can apply to more than just tasks.

The use of a separate class to store such constants is of course viable, but seems like a bit of unnecessary complication if all it does is hold values. I wouldn't recommend it unless the class had other purposes such as returning computed values based on those stored constants.

I usually store model choices directly in the model, since they don't generally apply anywhere else.

Whatever you do, try to keep it consistent.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54EADFC3.3020301%40dewhirst.com.au.

[Frankline]

The reason for my strategy here is because I will need to have a multi-select instead of a single select for choosing the TaskStatus in the form i.e. A Task can have one or more TaskStatus. 

Moreover, I will again have to create another class, SomeClass, which has a direct relation to the Task model, but can only be associated with only one TaskStatus available from the pool of TaskStatus' that were selected for that Task. (Not sure I'm making sense here)

So, YES, the class will be used to compute values based on the stored constants.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVgDVT2vreL41GjKBUV5MmxDWhwMWSM8Pg92-YCeNMrng%40mail.gmail.com.

[James Schneider]

>>> In my case, a Task can have one or more TaskStatus. I do not wish to store
>>> the TaskStatus in the database since they are simply constants.
>>>
>>> Does anyone have a better way of how I can approach this?
>>>

I just read this a bit closer. I think what you mean is that you don't want a separate enumeration DB table that lists all of your choices with their integer codes and then your statuses link to it via FK's, etc. That's perfectly fine, and that should be how it works since you have enumerated all of the possible outcomes in your tuples. Since you have provided a list of choices to Django, it will validate that only those choices are allowed when forms are submitted, etc. as a bonus.

TL;DR; Unless you've hit a specific problem, it looks like you are doing it right.

https://docs.djangoproject.com/en/1.7/ref/models/fields/#choices

-James