You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you happen to run tests with the --nodb option on an app that does in fact use the ORM to do CRUD operations on your database, it WILL corrupt whatever your default (not test) database is. You can test this by making a simple app, let's call it "myapp", with a single model, set up to use a SQLite3 database:
from django.db import models
class MyTable(models.Model):
a = models.IntegerField(primary_key=True)
And a single test:
from django.test import TestCase
from myapp.models import MyTable
class SimpleTest(TestCase):
def test_blow_away_everything(self):
MyTable.objects.all().delete()
Now run a syncdb and then manually insert a few rows into "myapp_mytable", and pretend this is your production DB. Run ./manage.py test normally and it is fine, of course. But run ./manage.py test --nodb; all your rows will have been deleted.
I presume this happens because --nodb doesn't do anything to prevent database access, nor does it set up a test database to replace/act as a proxy for your dev/production/whatever database.
Oddly enough, the problem does not seem to exist if using django.db.connection directly, instead of the ORM. I haven't looked into why that is.
I'd suggest 1) a strongly worded warning in the README and anywhere else appropriate, not to use this option, ever, on a database-backed app, 2) if possible, a modification to disable the ORM or access to the default database with this option turned on. Perhaps the runner could just quit if it encounters a test trying to use the ORM/database. --nodb is very useful for certain sets of tests that don't hit the database, but the user would need to make sure they specify the particular tests to run correctly every time, or else suffer potentially dire consequences. (As I unfortunately did.)
The text was updated successfully, but these errors were encountered:
I've added something to the readme just now. Thanks for the issue report and sorry it caused you some pain. I'll also have a look when I get chance about something that throws and exception if you do hit the database.
If you happen to run tests with the --nodb option on an app that does in fact use the ORM to do CRUD operations on your database, it WILL corrupt whatever your default (not test) database is. You can test this by making a simple app, let's call it "myapp", with a single model, set up to use a SQLite3 database:
And a single test:
Now run a syncdb and then manually insert a few rows into "myapp_mytable", and pretend this is your production DB. Run ./manage.py test normally and it is fine, of course. But run ./manage.py test --nodb; all your rows will have been deleted.
I presume this happens because --nodb doesn't do anything to prevent database access, nor does it set up a test database to replace/act as a proxy for your dev/production/whatever database.
Oddly enough, the problem does not seem to exist if using django.db.connection directly, instead of the ORM. I haven't looked into why that is.
I'd suggest 1) a strongly worded warning in the README and anywhere else appropriate, not to use this option, ever, on a database-backed app, 2) if possible, a modification to disable the ORM or access to the default database with this option turned on. Perhaps the runner could just quit if it encounters a test trying to use the ORM/database. --nodb is very useful for certain sets of tests that don't hit the database, but the user would need to make sure they specify the particular tests to run correctly every time, or else suffer potentially dire consequences. (As I unfortunately did.)
The text was updated successfully, but these errors were encountered: