Sentry with django-newauth
django-newauth is a library to add customizable user model (It developed before Django 1.5). And sentry is a platform to collect logs and aggregate these.
Sentry can collect errors raised by some django applications, and displays informations of these errors.
Problem
Sentry can tell us a user encountered some errors. But, if the application uses django-newauth, the user provided by newauth will not be displayed.
I tried to write a SentryPlugin to display the newauth’s user information. As it turns out, I could not do it. It was a difficult than I thought.
Solution
I wrote a package to solve this raven_django_newauth .
You can set SENTRY_CLIENT = ‘raven_django_newauth.client.DjangoNewauthClient’, and then, User interface of Sentry provides a information of newauth’s user.
Sentry and Raven
Sentry collects informations sended by raven. Sentry defines general interfaces (for example a User), and raven traslates collected data to thing in consideration of these interfaces. A client send dictionary thats key is path to each interfaces (like ‘setry.interfaces.User).
The User interfaces in sentry.interfaces.User. And on django application, the raven client is raven.contrib.django.client.DjnagoClient. The client gets user information from get_user_info method and stores to the dictionary as a key ‘sentry.interfaces.User’
Django’s TestCase.multi_db attribute is mistake
Django’s test framework (django.test.TestCase) has a atribute multi_db . It should be set True when testing on multiple databases (False, by default).
If you forget this setting, and your test uses multiple databases, the test suite only flushes the ‘default’ database (more exact django.db.utils.DEFAULT_DB_ALIAS) without flushing another databases.
And then, some trash datas will left on these databases (ignore the ‘default’ database). After tests will have risk of failing in absurd reason. I’m handling multiple databases on my work, and every time I forget setting this. And the mistake is difficlut to notice. Of cause, there are no errors. This is expected behavior.
This behavior (only flushing ‘default’) is feature for speeding up. Because, flushing a database is slow, and it will be run for each tests.
But, I think, it should be flush all databases by default.
If your application using multiple databases, but a TestCase use only ‘default’, then you can set ‘flush_only_default = True’ (for example) to force a test suite flushing only ‘default’ database.
Of cause, your application uses only ‘default’ database, only ‘default’ will be flushed even if without setting flush_only_default = True.
I think the behabior for speeding up is optional. By default, it should be performed as indubitable even if it will be slow.
The change for this will be like this:
diff --git a/django/test/testcases.py b/django/test/testcases.py
index a9fcc2b..0558476 100644
--- a/django/test/testcases.py
+++ b/django/test/testcases.py
@@ -466,11 +466,11 @@ class TransactionTestCase(SimpleTestCase):
def _databases_names(self, include_mirrors=True):
# If the test case has a multi_db=True flag, act on all databases,
# including mirrors or not. Otherwise, just on the default DB.
- if getattr(self, 'multi_db', False):
+ if getattr(self, 'flush_only_default', False):
+ return [DEFAULT_DB_ALIAS]
+ else:
return [alias for alias in connections
if include_mirrors or not connections[alias].settings_dict[
- else:
- return [DEFAULT_DB_ALIAS]
def _reset_sequences(self, db_name):
conn = connections[db_name]
I asked about this proposal on django developers IRC channel (#django-dev on freenode). Some people answered me (Thanks a lot!), in side disagree. Certainly, this proposal is not have great gain. and having a big risk breaking compabitity. I noticed this is not good proposal, but I still claim the multi_db behavior is mistake.
Yes, I will set multi_db = True on a base class, and subclassing it on own tests.