The current stable version of django-constance does not work out of the box on Django 1.6, which has now been released. The following exception is raised when viewing /admin:

AttributeError at /admin/
'Meta' object has no attribute 'object_name'

Now, this has been fixed with the following commit: https://github.com/comoga/django-constance/commit/987e13f1ae24b419574d09d88097f41b7bd6ffc1. However, this commit was merged three months ago and the latest django-constance release (0.6) was released eight months ago.

This forces users to install directly from Git if they are using Django 1.6. Instead, it would be great to see a new release of django-constance with the fix included.

The problem

I have a project with 50+ migrations in it and recently decided I want to use Constance for a couple of settings.

Everything was OK while developing/adding dynamic settings. I guess it's due to the fact that I setup the Constance config first, did the migration and only then start to use dynamic settings values.

Although when I want to do a test deploy (i.e. when starting up a new Vagrant VM) and run all the migrations from scratch it fails. I am unable to run python manage.py migrate database, python manage.py migrate or even python manage.py showmigrations.

  File "/vagrant/my_app/views.py", line 138, in MyViewSet
    my_variable = constance_config.MY_VARIABLE
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/utils/functional.py", line 239, in inner
    return func(self._wrapped, *args)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/constance/base.py", line 19, in __getattr__
    result = self._backend.get(key)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/constance/backends/database/__init__.py", line 74, in get
    value = self._model._default_manager.get(key=key).value
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/query.py", line 374, in get
    num = len(clone)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/query.py", line 232, in __len__
    self._fetch_all()
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/query.py", line 1118, in _fetch_all
    self._result_cache = list(self._iterable_class(self))
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/query.py", line 53, in __iter__
    results = compiler.execute_sql(chunked_fetch=self.chunked_fetch)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/sql/compiler.py", line 894, in execute_sql
    raise original_exception
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/models/sql/compiler.py", line 884, in execute_sql
    cursor.execute(sql, params)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/backends/utils.py", line 80, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/utils/six.py", line 685, in reraise
    raise value.with_traceback(tb)
  File "/home/ubuntu/.virtualenvs/venv/lib/python3.5/site-packages/django/db/backends/utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "constance_config" does not exist
LINE 1: ...ce_config"."key", "constance_config"."value" FROM "constance...

So a table that is about to be created is referenced already.

System configuration

• Django version: 1.11.3
• Python version: 3.5.2,

Added in a hook to check for Django version on model creation. Not sure if this is the best way to get V1.8 compatibility, but it works for all my purposes.

Cheers, Jonathan

As an FYI, "Takedown Piracy LLC" sent a DMCA takedown notice for this repository to google on Dec 24th.

The notice is posted at chilling effects... https://www.chillingeffects.org/notices/10281020

and less exactly on google's transparency site (doesn't list exact github urls) http://www.google.com/transparencyreport/removals/copyright/requests/1763826/

There's an article describing this problem here which made slashdot. http://motherboard.vice.com/read/porn-companies-are-going-after-github

I just happened to notice and thought you might want to know.

Describe the problem

Tell us about the problem you're having.

I was trying to install djangorestframewok and i installed it then i had an issue running the server have attached the image file

(localdev-EUbEEbsi) C:\Users\ASUS\Desktop\localdev\ecom>python manage.py runserver Watching for file changes with StatReloader Performing system checks...

Exception in thread django-main-thread: Traceback (most recent call last): File "c:\users\asus\appdata\local\programs\python\python38-32\lib\threading.py", line 932, in _bootstrap_inner self.run() File "c:\users\asus\appdata\local\programs\python\python38-32\lib\threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "C:\Users\ASUS.virtualenvs\localdev-EUbEEbsi\lib\site-packages\django\utils\autoreload.py", line 53, in wrapper fn(*args, **kwargs) File "C:\Users\ASUS.virtualenvs\localdev-EUbEEbsi\lib\site-packages\django\core\management\commands\runserver.py", line 118, in inner_run self.check(display_num_errors=True) File "C:\Users\ASUS.virtualenvs\localdev-EUbEEbsi\lib\site-packages\django\core\management\base.py", line 392, in check all_issues = checks.run_checks( File "C:\Users\ASUS.virtualenvs\localdev-EUbEEbsi\lib\site-packages\django\core\checks\registry.py", line 70, in run_checks new_errors = check(app_configs=app_configs, databases=databases) File "C:\Users\ASUS.virtualenvs\localdev-EUbEEbsi\lib\site-packages\django\core\checks\urls.py", line 101, in check_url_settings if value and not value.endswith('/'): AttributeError: 'tuple' object has no attribute 'endswith'

Steps to reproduce

Tell us how to reproduce it.

System configuration

• Django version:
• Python version:3.8.5
• Django-Constance version:

i think sometimes we need to make a block for differents types of values, for example, encapsulate finances values like tax and parity.

so, i modify the code for add this function without break the Backward compatibility. new config looks like this:

CONSTANCE_CONFIG = { 'TEST_1': (42, 'Answer to the Ultimate Question of Life, The Universe, and Everything'), 'TEST_2': ('prueba', 'string test'), 'TAX': (0.16, 'Tax','Finances'), 'USD_TO_MXN': (16.40, 'Dollar to mexican pesos','Finances'), }

where finances is the new block

override_config is currently possible to apply only to unittest TestCase classes. This PR adds constance.test.pytest module that can be used as follows

Examples can be found in doc

It's still possible to do import as usual for unittest

from constance.test import override_config

...

The doc claims that 1.1 adds support for Django 1.8 and 1.9, while <=1.6 are not supported any more. That's fine, except that 1.7(.10) support also seems to be gone. When clicking on the config in django admin, one gets:

TypeError at /admin/constance/config/ object of type 'Config' has no len() ... Exception Location: .../python2.7/site-packages/django/utils/functional.py in inner, line 225

This is while using pyhon 2.7. The net result is that one has to upgrade constance exactly at the time of a django upgrade, which is suboptimal. Is this really the case?

@jezdez

If trying to save a datetime type setting getting this in Django 1.5.4:

TypeError
Exception Value:    
can't compare offset-naive and offset-aware datetimes
Exception Location: constance/admin.py in changelist_view, line 119

• http://stackoverflow.com/questions/7065164/how-to-make-an-unaware-datetime-timezone-aware-in-python
• http://stackoverflow.com/questions/796008/cant-subtract-offset-naive-and-offset-aware-datetimes

Hello. I would like to forward the request to the instance of ConstanceForm, when calling the save method. Help me understand if it is necessary to update any tests.

Backporting command function from https://github.com/NZME/django-constance-cli in as requested by @jezdez in NZME/django-constance-cli#2

Basic usage:

./manage.py constance list
./manage.py constance get FOO
./manage.py constance set FOO bar

A couple of issues to discuss before merging:

• ~~Should it be possible to disable this command functionality? I could do this by moving the command to a sub-app (eg constance.cli), or with a setting?~~ ** I'm not sure it's necessary to allow this to be disabled (eg, I don't think it's a security risk - if you've got manage.py access then you can do anything anyway).
• ~~The command line syntax could be expanded or altered, I've loosely modelled it on git config, any better suggestions?~~ ** I've updated as per discussion to positional arguments

Describe the problem

Using django-constance with pytest causes race-condition in settings load because of a misplaced import:

https://github.com/jazzband/django-constance/blob/b6f8e2c5b8e151b0a58ae999991580a3c1a1e28c/constance/init.py#L3

Django documentation recommends in [link]:

Lastly, your check function must be registered explicitly with system check registry. Checks should be registered in a file that’s loaded when your application is loaded; for example, in the AppConfig.ready() method.

This is how the race-condition happens:

1. Pytest plugin manager loads the constance/test/pytest.py file
2. The constance/test/pytest.py file refers to constance/__init__.py in: https://github.com/jazzband/django-constance/blob/b6f8e2c5b8e151b0a58ae999991580a3c1a1e28c/constance/test/pytest.py#L8
3. The constance/__init__.py causes checks to be registered in: https://github.com/jazzband/django-constance/blob/b6f8e2c5b8e151b0a58ae999991580a3c1a1e28c/constance/init.py#L3
4. Important: This happens before pytest-django can set up Django here
   1. Whenever checks are loaded, it will cascade-load Django checks as well
   2. Django checks will try to load internal stuff like caches and database
   3. Whenever Django detects cache/database isn't configured, it will configure them before knowing what the final state of settings would be
5. Pytest plugin manager will now trigger all the hooks for plugins to load correctly (eg. pytest_configure)
6. The pytest-django plugin finally sets settings up - this is when constance should register its checks
7. Important: Now if you compare django.conf.settings with django.db.connections.settings they can likely be different as below:

(Pdb) from django.conf import settings
(Pdb) p settings
<dynaconf.base.LazySettings object at 0x1127de640>
(Pdb) p settings.DATABASES
<Box: {'default': {'NAME': 'local', 'USER': '', 'PASSWORD': '', 'HOST': 'localhost', 'PORT': '', 'CONN_MAX_AGE': 500, 'ENGINE': 'django.db.backends.postgresql_psycopg2'}}>
(Pdb) from django.db import connections
(Pdb) p connections
<django.db.utils.ConnectionHandler object at 0x111fa4c40>
(Pdb) p connections.settings
{'default': {'ENGINE': 'django.db.backends.dummy', 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'CONN_MAX_AGE': 0, 'OPTIONS': {}, 'TIME_ZONE': None, 'NAME': '', 'USER': '', 'PASSWORD': '', 'HOST': '', 'PORT': '', 'TEST': {'CHARSET': None, 'COLLATION': None, 'MIGRATE': True, 'MIRROR': None, 'NAME': None}}}

Steps to reproduce

I think this really depends on your set up. I was able to reproduce it using dynaconf probably because of the way it overrides Django settings. Nonetheless, I'm sure that if constance can load checks correctly this shouldn't be a problem.

System configuration

• Django version: 3.2
• Python version: 3.9
• Django-Constance version: 2.7

Describe the problem

Sentry is reporting that constance is performing a n + 1 query whenever the main page of my website loads. Strangely the main page does not use any configuration values from constance (as far as I can tell).

Repeating query

SELECT "constance_config"."id", "constance_config"."key", "constance_config"."value" FROM "constance_config" WHERE "constance_config"."key" = %s LIMIT 21

System configuration

• Django version: 4.1.3
• Python version: CPython 3.10.6
• Django-Constance version: [database] 2.9.1

Describe the problem

Using the Redis Backend, and calling config.VARIABLE repeatedly for the many variables slows down the performance ((tested)).

I ask, from a theoretic standpoint:

Is there something to gain from wrapping the calls to constance values with an in-memory cache (e.g get_constance_value(value, cache_ttl)) that will get the value from Redis the first time, and keep it in-memory (e.g. for 60 seconds)?

Describe the problem

It seems disabling django admin's app breaks the constance CLI. As I noticed constance/management/commands/constance.py imports ConstanceForm and get_values from admin configuration. The problem is admin.py tries to register the constance's config class and since the admin app is not present in INSTALLED_APPS django throws a LookupError.

I think splitting ConstanceForm and get_values to a separate module (like forms.py) and importing them directly from that module can easily fix the problem.

Steps to reproduce

1. Remove django.contrib.admin from INSTALLED_APPS (And its URL pattern)
2. Run python manage.py constance --help

System configuration

• Django version: 4.0.7
• Python version: 3.10.7
• Django-Constance version: 2.9.1