Newbie Question - Where to store application constants?

[Mark Phillips]

Where should one put application specific constants - those that change sometimes(1) and those that never change? For example, I am creating a simple inventory application for my mother's estate. Several quotes for her jewelry are based on the weight of the jewelry and the current price of gold.

In the Estimate model, I have a field for weight, and then a property that looks something like:

@property

def estimate_by_weight():

    return self.weight * PRICE_OF GOLD

Where would I put the PRICE_OF_GOLD constant? Some ideas that came to mind:

1. Settings.py - but then I have to edit that file every time I want to update the price of gold

2. Maybe a model so I can update it in the admin screens?

3. A form somewhere? But I think this would mean a model, so this is probably the same as #2.

Where would one put a non-changing constant like the speed of light in a django application? 

Thanks!

Mark

(1) Yes, I realize that terms 'constant' and 'changes sometimes' are mutually exclusive, but I hope you get the gist of what I am asking regardless of my imprecise description..

[Bill Freeman]

It depends on the complexity of the issue.

The price of gold does fluctuate.  On the grounds that I might want to change it more often than I would want to ssh in, edit a file, and restart, I would tend to put price of gold in the database, that is, in a model of which there may only be one instance.  Implementing limits on who has permission to change it is a separate fun topic, which may not be needed if very few people have admin logins.

Then there are application specific configuration options, which tent to never change once an installation is up and running.  You can require that they be set in settings.py if the constants are highly likely to differ site to site (or if there is only one site in the world using this app), but it is probably worthwhile providing defaults which can be overridden in settings.py .  A common way to do the latter is to have another settings file in the app directory (usually also called settings.py, since it can be qualified with the app name) which defines constants as the result of calling gettattr on the main settings object, and providing the default value as teh third argument to getattr.  The other parts of the app get the constants from the app specific settings file.

Another kind of constant is truly never expected to change, such as physical or algorithmic constants, defined so that they can be used symbolically.  Sometimes they are only used quite locally, and can be defined in that module, but if they are used by two or more modules, they should probably be defined once, and imported in modules that use them.  While it is possible to define them in any module (such as the one that uses them the most) and to import from that module in others that need the constant(s), you must beware of circular import problems, so it is often easier to create a constants.py or the like (if you already have an app specific settings module, it is a fine place for you constants).  But your models.py module, if you have only one, is a pretty safe place to put constants, since it doesn't tend to import your other modules (unless you have an app specific settings module), so you won't (typically)  have circularity if you import from it.

Bill

--
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/CAEqej2OuRC%3D5c2AwKkLRV0%2BGQJMBd6g2wM41mRZB1RCpMtOshw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Phillips]

Thanks! Very clear and helpful.

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0tCsz6XSb4T4gziZFzUxG%3DnHxmMe_Zj7n%3D3P%3DgEZ7s7rQ%40mail.gmail.com.

[Camilo Torres]

To round this, for the price of gold, and if you are using the django.contrib.admin interface, you can use Django Solo or similar singleton model. That way you can edit your "business properties" within the admin interface:

https://pypi.python.org/pypi/django-solo

[C. Kirby]

I would suggest that your example, the price of gold, isn't a constant. If you want to treat it as such then I agree with the above answers. However, you could also look around for APIs that publish commodities values and actually pull the real values in real (or semi real) time.

[Mark Phillips]

Kirby,

You have a good point. However, in this use case I am dealing with a jewelry store buying gold at their "market" rate. It is not the same as owning gold and the value changes based on a published (ie available through an API) rate. The jewelry store market rate for gold changes slowly, and from store to store So, I found creating a table called constants in the database allows me to change the value as needed and not have to touch the app code. 

Mark

On Mon, Feb 17, 2014 at 10:20 AM, C. Kirby <mis...@gmail.com> wrote:

I would suggest that your example, the price of gold, isn't a constant. If you want to treat it as such then I agree with the above answers. However, you could also look around for APIs that publish commodities values and actually pull the real values in real (or semi real) time.

--
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/236a1a12-151d-4730-af8c-c5cdc30a0287%40googlegroups.com.