#22002: AppConfig.ready() and tests
--------------------------------------+------------------------------------
Reporter: mjtamlyn | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: master
Severity: Release blocker | Resolution:
Keywords: app-loading | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by mjtamlyn):
I discovered this accidentally investigating (bad) solutions for #22022. I
propose just docs. At the moment, `manage.py test` is not special cased in
the core management. We call `django.setup()` and then branch on the
command used. I think that we should:
1) recommend never interacting with the database in `ready()` (or in
startup code in general - this is what migrations are for right?)
2) mention that it would be run against the main database even in testing
I don't think it's actually that big a deal about the test/prod situation.
Such code would be run *every time* you call a management command of any
kind, so you'd soon find out if you were breaking the db. We could
theoretically explicitly error during the calls to `ready()` if we try to
obtain a connection cursor, but that would be a bit dirty in its
implementation.
--
Ticket URL: <https://code.djangoproject.com/ticket/22002#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.61f2ea5ea914c3668a6f5d566d18376d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
