I have a django project and I am trying to write some tests for it. However, my initial_data fixtures cause an error when running the test.
The error that I am getting is:
django.db.utils.ProgrammingError: Problem installing fixture 'accounts/fixtures/initial_data.json': Could not load auth.Group(pk=1): relation "auth_group" does not exist
LINE 1: UPDATE "auth_group" SET "name" = '...
If I rename my fixture to something other than initial_data so that it doesn't get loaded by default, it works, but I don't want to rename my fixtures, because that would mean that I can no longer run loaddata without arguments.
I have found this bug, but my project does not have any initial migrations. Also, I have other fixtures which are loaded just fine.
So far, I have tried:
flushing my development database, as well as deleting any possible migration files
deleting and re-creating my virtual env
changing the order of my apps in INSTALLED_APPS
calling the flush command in the .setUp() method.
I should mention that I am using the APITestCase from django-rest-framework.
Any suggestions are welcomed. Thanks.
Ok, so finally, it seems that the problem wasn't just when I was testing. When I changed back to running my server, I noticed I was getting the same error.
Every single similar problem I found had something to do with migrations, but I didn't even had those, because running ./manage.py makemigrations was not generating them.
So I ended up doing ./manage.py makemigrations *app_name* for each of my apps, and everything started working again ...
Related
This is a very simple issue but may take a long time resolve if you fail to look at the correct point. Especially there's not much content online to hint the source of the problem.
I have a Django project of version 3.2.5.
I created a new model: app.model. Then I ran python manage.py makemigrations app command.
When I ran the tests via pytest, I got the following errors:
E psycopg2.errors.DuplicateTable: relation "app_model" already exists
E django.db.utils.ProgrammingError: relation "app_model" already exists
However there's no such table neither on my local database nor in test database which is created from scratch.
I pushed my code on a branch to Github and build succeeded online with no problems. However my test suite complained about this existing table. I ran python manage.py migrate app and it worked.
I realized it is a problem caused by using pytest with --reuse-db argument. It doesn't ask you to delete an orphan test database in this case, it reuses it.
Instead of using pytest, when I run python manage.py test, I got the following prompt:
Type 'yes' if you would like to try deleting the test database 'test_project', or 'no' to cancel: Got an error creating the test database: database "test_project" already exists
I typed yes, the orphan test_project database was deleted & re-created from scratch and the errors disappeared.
Another solution would be using --create-db with pytest command or adding this option to the pytest.ini file.
I made two changes to different models in my database.
The first
operations = [
migrations.DeleteModel(
name='Settlement',
),
]
And the second:
operations = [
migrations.RemoveField(
model_name='invoice',
name='settlement_deducted',
),
migrations.RemoveField(
model_name='invoice',
name='settlement_supporting',
),
]
The issue is that they ran in this order, and the second one failed. The field being removed in the second migration uses the "Settlement" model, but since that model was deleted in the first migration it throws this error:
ValueError: The field invoices.Invoice.settlement_deducted was declared with a lazy reference to 'accounting.settlement', but app 'accounting' doesn't provide model 'settlement'.
The field invoices.Invoice.settlement_supporting was declared with a lazy reference to 'accounting.settlement', but app 'accounting' doesn't provide model 'settlement'
Now when I try to do anything to fix it, it seems to just be stuck in that error state and continuously throws that same error.
I have tried reverting the first migration to the previous migration on that model, adding that model back in and running makemigrations and then migrate so that the Settlement model exists again, and deleting the second migration (though it was never run anyway). All of these options are still throwing the same error.
I am surprised that Django didn't catch this dependency issue for me, but it is unfortunately too late for that now. I also tried adding it as a dependency, but then it just threw the error saying that a migration has been migrated before one of its dependencies.
I was successfully able to solve the issue! These are the steps I took:
add the second migration as a dependency to the first one
go to the django_migrations table in the db and delete the first migration (which ran already)
run ONLY the second migration
fake the first migration (since it already ran)
(unnecessary step but necessary in my case) run migrate normally to finish migrating uninvolved migrations from other apps
insite try this
py manage.py migrate <yourappname> zero
then go in the same app folder and in that migration folder delete all the file except pycache and init.py and then again try to run
py manage.py makemigrations
py manage.py migrate
and please do replace py with python if you are using any other Os then windows what the migrate zero do is it delete all the migration of your app and after again doing the migration it will get everything back for you
and tell me if you still got any other error
I'm trying to deploy a django CMS app to PythonAnywhere or Heroku but I keep getting this error on Heroku:
ProgrammingError at /
relation "cms_urlconfrevision" does not exist
LINE 1: ...sion"."id", "cms_urlconfrevision"."revision" FROM "cms_urlco...
and this error on PythonAnywhere:
OperationalError at /
no such table: cms_urlconfrevision
The app works fine on localhost.
I understand it's a database table missing but I have no idea how to fix it. I tried removing all the migration files and .pyc files and migrated again, I removed the database, I tried migration with --fake. Nothing seems to work.
I'm using
django-cms==3.6.0
Django==2.1.8
I understand it's a database table missing but I have no idea how to fix it. I tried removing all the migration files and .pyc files and migrated again, I removed the database, I tried migration with --fake. Nothing seems to work.
Migration files just define what migrations exist. They don't modify your database by themselves. There are two steps here:
Creating migrations with makemigrations. This should only be done on your development machine. By the time your code is being deployed you shouldn't have any model changes that would cause new migrations to be generated.
Applying migrations to your database with migrate. This must be done in development (to update your local database) and also in production (to update your production database).
On Heroku, you'd run your migrations with
heroku run python manage.py migrate
I think this is the step you're missing.
Hello maybe you found the solution but if the is somebody coming across that issue, it due to the database settings.
In project_name/site_name/settings.py and database settings section
Change
NAME: 'project.db'
to
NAME:'project_name/project.bd'
in the file setting.py change
'NAME': 'project.db',
to
'NAME': BASE_DIR / 'project.db',
worked for me
As I was changing my models.py and migrating, I got an error message saying:
python manage.py makemigrations project_profile
CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0033_auto_20180217_0912, 0036_auto_20180217_0927 in project_profile).
To fix them run 'python manage.py makemigrations --merge'
So, when I tried to follow the instructions, I got another error that one of my tables that the merged migration is now depending on do not exist anymore (I renamed it). Interestingly enough, this renaming took place during the merge operation. So, really Django should have known about it in the first place.
To resolve the situation, I deleted prior migrations up to and including the migrations that was not applied, the one that caused all the headache. I tried to makemigrations and migrate again. But, Django now throws another error saying some of the models it wants to create in the database already exist. Obviously, I do not want to delete those tables and loose all that information to appease Django. So, I had to resort to some hacking solutions and actually change those tables manually and do a fake migration in order to stop Django from complaining.
Having said all of that, I feel like there should be a more logical way about this. How do I resolve migrations during the merging?
I had the same issue, Then I was able to solve this by deleting the migrations file that django pointed out and starts with name auto. It occurred 2-3 times before it finally gave up and finally worked.
Alternatively you can django-dbbackup or django-import-export packages to backup the tables then clean your database and migrations. Then you can restore them back to the same state once migrations are stable.
Sources
dbbackup : https://django-dbbackup.readthedocs.io/en/stable/
import-export : https://django-import-export.readthedocs.io/en/latest/index.html
I have an app that I recently did a migration for that included adding a new table. I can see that the migration worked, the table is populated, I can access it, etc. Even when I run
python manage.py migrate my_app -l
I can see the migration as having been successfully run.
However when I run my unit tests I get:
OperationalError: no such table: my_app_my_table
The only thing I can thing of is that the in memory database is not running all the migrations? Or it's not doing it correctly? Any help would be greatly appreciated.
It could be the case that your migrations aren't actually generating the SQL code you intended, and it's probably worth running sqlmigrate on the specific migrations to make sure it's generating code to make the table.
If the SQL code looks right, something weird could have happened and django thinks you ran the migration but it didn't actually change the database. In that case, you could try restoring an older version of the database and running the migrations on that?