Open alastair opened 9 years ago
yeah...
I have this embarrassing helper function in the tests.py for some of my projects that use django-badges:
def generateBadges():
from badges.utils import registered_badges
for badge in registered_badges.values():
delattr(badge, "_badge")
badge.badge
I'll take a look at AppConfig.ready, thanks for the pointer
Actually, looking over it now, it has a scary disclaimer about doing queries in AppConfig.ready:
Warning
Although you can access model classes as described above, avoid interacting with the database in your ready() implementation. … For example, even though the test database configuration is separate from the production settings, manage.py test would still execute some queries against your production database!
I've been chasing down a problem with badges not being in my database when I run unit tests. It's related to the
registered_badges
dictionary.The
post_syncdb
hook inlisteners.py
creates database objects based onMetaBadge
s and populatesBadge._badge
with a reference to the model. However, my transaction-wrapped unit tests truncate the database at the beginning and end of each test. Now the database is empty but theBadge
believes it still has an object.In the end, I've solved it by running this in my
setUp
method:My view is that a method like
sync_badges_to_db
should always create badges in the database, or maybe there should be a method to force this.More generally the
post_syncdb
hook inlisteners
has been causing problems too - in fact, the django documentation for this hook explicitly says that it's not recommended to change the database in this hook: https://docs.djangoproject.com/en/1.7/ref/signals/#post-syncdb I understand that it's a useful way of making sure the database reflects the MetaBadges, but it feels like magic that is a little bit unexplained. I prefer the current system to when badges were created in__new__
, but I would like it more if badge creation was explicit. Maybe now django 1.7'sAppConfig.ready
could be something to look at.