[Django] #17656: collectstatic should not require a database
Django
-------------------------------------+--------------------
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Component: contrib.staticfiles | Version: 1.3
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+--------------------
The collectstatic command, like all management commands, gets a call to
self.validate() which requires a database to be up and running. This is
annoying, because this command has no need for the database at all, and
may well be run during packaging/deployment where a database may not be
present.
Although hypothetically the STATICFILES_STORAGE setting could refer to
something that stores static files in a database, the behaviour should be
made more convenient for the default.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by claudep):
* needs_docs: => 0
* needs_better_patch: => 0
* version: 1.3 => SVN
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
There is a flag called 'requires_model_validation' that commands can unset
to not require validation.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:1>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: closed
Component: contrib.staticfiles | Version: SVN
Severity: Normal | Resolution: fixed
Has patch: 0 | Needs documentation: 0
Changes (by jezdez):
* status: new => closed
* resolution: => fixed
Comment:
In [17514]:
{{{
#!CommitTicketReference repository="" revision="17514"
Fixed #17656 -- Stopped the collectstatic management command from running
the database validation. Thanks, jcspray.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:2>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by anonymous):
* status: closed => new
* resolution: fixed =>
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:3>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
This is broken again.... it loads translations here:
https://github.com/django/django/blob/master/django/core/management/base.py#L284
Which loads everything, any requires a database
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:4>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
I meet this bug on django version 1.4.10. when trying to write a multiple
machine deployment script. I've stoped the database connection to avoid
extra database hiting during the deployment. but collectstatic command
still waiting for database connection until it is timed out.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:5>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: closed
Component: contrib.staticfiles | Version: master
Severity: Normal | Resolution:
Has patch: 0 | Triage Stage: Accepted
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by claudep):
* status: new => closed
* resolution: => worksforme
Comment:
This should not happen any more on a recent version of Django. Please
provide a traceback if you can reproduce.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:6>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MattBlack85):
* status: closed => new
* resolution: worksforme =>
Comment:
reopening, it seems like it still checks the database. In this case I just
changed name and password.
{{{
Traceback (most recent call last):
File "manage.py", line 12, in <module>
execute_from_command_line(sys.argv)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/core/management/__init__.py", line 385, in
execute_from_command_line
utility.execute()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/core/management/__init__.py", line 354, in execute
django.setup()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/__init__.py", line 21, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/apps/registry.py", line 108, in populate
app_config.import_models(all_models)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/apps/config.py", line 197, in import_models
self.models_module = import_module(models_module_name)
File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/auth/models.py", line 40, in <module>
class Permission(models.Model):
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/models/base.py", line 125, in __new__
new_class.add_to_class('_meta', Options(meta, **kwargs))
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/models/base.py", line 300, in add_to_class
value.contribute_to_class(cls, name)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/models/options.py", line 166, in contribute_to_class
self.db_table = truncate_name(self.db_table,
connection.ops.max_name_length())
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/__init__.py", line 40, in __getattr__
return getattr(connections[DEFAULT_DB_ALIAS], item)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/utils.py", line 243, in __getitem__
conn = backend.DatabaseWrapper(db, alias)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/gis/db/backends/postgis/base.py", line 14, in
__init__
self.ops = PostGISOperations(self)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/gis/db/backends/postgis/operations.py", line 166,
in __init__
if self.spatial_version < (1, 3, 4):
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/utils/functional.py", line 55, in __get__
res = instance.__dict__[self.func.__name__] = self.func(instance)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/gis/db/backends/postgis/operations.py", line 260,
in spatial_version
vtup = self.postgis_version_tuple()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/gis/db/backends/postgis/operations.py", line 434,
in postgis_version_tuple
version = self.postgis_lib_version()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/gis/db/backends/postgis/operations.py", line 414,
in postgis_lib_version
return self._get_postgis_func('postgis_lib_version')
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/contrib/gis/db/backends/postgis/operations.py", line 404,
in _get_postgis_func
with self.connection.temporary_connection() as cursor:
File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__
return self.gen.next()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 543, in
temporary_connection
cursor = self.cursor()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 165, in cursor
cursor = self.make_debug_cursor(self._cursor())
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 138, in _cursor
self.ensure_connection()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 133, in ensure_connection
self.connect()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 133, in ensure_connection
self.connect()
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/__init__.py", line 122, in connect
self.connection = self.get_new_connection(conn_params)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/django/db/backends/postgresql_psycopg2/base.py", line 134, in
get_new_connection
return Database.connect(**conn_params)
File "/home/matt/repos/uwncom/lib/python2.7/site-
packages/psycopg2/__init__.py", line 164, in connect
conn = _connect(dsn, connection_factory=connection_factory,
async=async)
django.db.utils.OperationalError: FATAL: role "234124323" does not exist
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:7>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I'd guess this is probably impossible (or at least quite difficult) to
make possible after the app loading refactor since all management commands
now fully initialize Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:8>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by carljm):
I think ideally "fully initialize Django" should not be equivalent to
"require database connection." But you may be right that this will be
difficult in practice.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:9>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
MattBlack85, the traceback shows that this is a PostGIS specific issue.
I've created a new ticket to track that issue: #23514.
Now it is possible that this happens with a plain PostgreSQL connection,
too, but it would be worth a try.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:10>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by MattBlack85):
claudep, you're right, if I switch to postgres I can't reproduce this
behaviour. This can be then closed, I'm going to add the traceback to the
new ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:11>
Django
Reporter: jcspray@… | Owner: nobody
Type: Bug | Status: closed
Component: contrib.staticfiles | Version: master
Severity: Normal | Resolution:
Has patch: 0 | Triage Stage: Accepted
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by claudep):
* status: new => closed
* resolution: => worksforme
--
Ticket URL: <https://code.djangoproject.com/ticket/17656#comment:12>