I have added foreign keys to some of the models in a Django application but the changes are not being reflected in the MySQL database even after migrating them. I have tried deleting all the previous migrations and then redoing but had no success. What could be the issue here?
that could have many reasons which i need more details to say exact answer, but i can say my previous experiences that solved migrations error. first if you want to do migrations again you should delete all tables plus your migrations files ( IMPORTANT NOTE: you should not delete migrations folder and you should not delete __ init __.py file in migrations folder which make migrations folder a module if you deleted it just make an empty one yourself) and sometimes because of an error in your models, your migrations does not completely migrate so if you migrate again it say some tables are duplicated so you should fix the errors and bugs, delete all tables and migrations like i just said and migrate again.
Related
I have a problem with TypeORM migrations telling me that some fields don't exist or there are duplicate keys when I try to run them in a new deployment.
Is it possible to delete all migrations and recreate just one with my current entities?
Stack:
TypeORM
NestJS
MySQL
Yes, it is possible to delete all migrations and recreate one.
Remove all migration files from your src/migrations folder.
Don't forget to delete data from migration table in your database. In typeorm, typically the migration table is called as typeorm_migrations.
Regenerate the migration file for your current entities. Use typeorm command npx typeorm migration:generate -n NameOfYourMigration.
After generating migration file, apply the changes to your database with npx typeorm migration:run
I've been working on making an auto-deployment system to make updating my django site easier, and it mostly works, but right now my database changes are screwy. I have the auto deployment run "makemigrations" "migrate" then "syncdb"
The trouble I have is when I run migrate, it tells me that my table already exists and can't be created. Previous answers have said to run "migrate --fake", but if I do this, it appears to think everything is up to date. The issue then is that I run "makemigrations" or "migrate" and it says no changes detected (even though there is a missing column from my database). I tried to run "sqlall" to figure out what it thinks the database should be, and it tells me that I have pending migrations. So I tried running "migrate" and it said no migrations exist.
How do I manage this? And in the future, what should I do for database migrations to troubleshoot/fix these problems?
Thanks
I fixed the problem. The issue stemmed from a misunderstanding of how Django migrations worked. Also, as per the comments, syncdb is no longer a command in manage.py.
The original issue was that I had been using a different database for deployment and then I switched and my migrations were out of sync from my development database, so I had to clear out both databases and migrations and start over with my data. Then I run makemigrations on my local machine and migrate there (for my dev DB). Then I upload to the server and have the fab script run migrate on the server production DB without calling makemigrations. This seems to have fixed the issue.
I have deleted the migration files in rails project. Now i want run the rails project in another system for that i need the migration files to create the table. please tell me how to create the migration files for already created tables in rails.
You still have db/schema.rb file containing all tables and their details..you can use it by rake db:schema:load,this will load the schema into the database, which is faster than running all the migrations.
NEVER DELETE YOUR MIGRATION AND MAINTAIN IT IN SUBVERSION/GIT
I have situation here, I have a database in production environment, and now I have to add few columns in table and drop 1 table from the database. I ran all the migrations such as rails g migration AddDeskToHelper desk:string and similar for dropping a table.
But now I want to upload this new generated schema into existing database without deleting any data from the database.
I'm searching about it and did not find any accurate answer.
For example, here
it says that rake db:schema:load deletes all the data from Database in production environment.
Kindly help me in this case.
If you have created the migrations to add some cols in existing tables or delete some tables, the rake db:migrate RAILS_ENV=production command will perform an "ALTER table..." without destroying your data, except you are dropping a col or table with data content.
But it's always recommended to perform a database backup before altering your production database.
So my Mac went down and now trying to build my project on my new Mac. I need to know when running rake db:migrate does it look at the schema.rb file?
As I am getting
Mysql::Error: Table 'myproject_development.users' doesn't exist: SHOW FIELDS FROM `users`
Even when I run rake db:migrate:up VERSION=001 which has no reference to users I get the same error?
If it matters my migrations start like
001_...
002_...
003_...
20100222171241_...
The migration code generally doesn't look at the schema file. It looks at the names of all the migration files and the database table called schema_migrations, and determines which migrations haven't been run yet. (I believe it does dump the schema at the end of running migrations.) Either your missing a migration, or your schema_migrations table is out of sync with your database.
After making a backup, you can start to troubleshoot. Do you have a migration that creates the users table? If not, where did it go? If you have it, why isn't it running?
FYI The migrations that start with numbers (eg. 001) are older versions of migrations. Sometime around 2.2 or 2.3 the names of the migrations were changed to dates, which is what you are seeing in the later migrations.
There may be a problem with the way those first few migrations are named, and they are not being found (I can't remember the migration story when this naming scheme switched). And maybe it tracked the migrations differently back then so there may be some futzing to make it work with the more modern scheme. You can fairly safely rename them following the new scheme, using the datestamp of the file.
Hope this helps.