so I went to create some migrations of some tables
and was hitting the up arrow and changing the --create"name" but was leaving the class name the same on accident after I already created some I noticed and tried renaming the files and classes but ran into problem I migrated and got errors I tried renaming them back and resseting and rolling back but everything is too messed up I dropped the tables manually and when I try to reset or rollback now I get a table does not exist error is there any easy way to get out of this mess with out having to create a new project?
If you mess up your migrations (can happen if you have migrated and change directly in the migrations), you can always just drop all tables and run a fresh php artisan migrate.
It sounds like you had migrated, and changed the tablenames of some tables. When you do that and try to rollback (reset starts out with rolling back) it tries to drop the tables, but when it gets to the changed tablename it can't find it in the database and you get an error saying the table doesn't exist :)
Related
Until now, I used the hasura console to update my database schema (new column, table and manage permissions). Every time a change is made, a new migration is created.
Today I added two columns and updated the permissions (select/insert/update).
For some reason, I deleted and recreated my database. Every migrations worked fine but not the permissions. I have my new columns in my tables but the permissions are not persisted and I can't understand why...
The last time I updated permissions, the metadata file changed but not now. I don't really understand this part of hasura, even with the documentation.
Any idea?
Several months ago, I was working late and needed to create a new column for a postgres table. I added the column through the command line using the standard heroku/postgres commands. I quickly realized how silly this was, deleted the column and then created the necessary migration to add it.
I recently took that laravel app and created a pipeline with it as the production app. I created a new staging app and set up a database for it. When I ran the migrations, I got an error saying that a column already existed. As you may have guessed, this is the same column that I had messed up before.
Since the migration failed after the database was created, I was able to delete the column in question, rerun the migration, and everything was OK. I do not understand why the column already existed except to guess that it was some artifact of my adding it manually (there was no error in the migrations).
I am worried that this same error will happen when I push the staging code to production and have to rerun my migrations. Obviously, in the production app I can't just delete the column in question as it has data.
Any ideas as to why this would happen and what I could do to fix the issue if it arises when I push the code into production?
As per laravel doc, To rollback the latest migration operation, you may use the rollback command. This command rolls back the last "batch" of migrations, which may include multiple migration files:
php artisan migrate:rollback
You may rollback a limited number of migrations by providing the step option to the rollback command. For example, the following command will rollback the last five migrations:
php artisan migrate:rollback --step=5
The migrate:reset command will roll back all of your application's migrations:
php artisan migrate:reset
You can check here. But i need to remove the specific migration file. As per my project having 30-40 migration file. I want to remove one of the migration file and its model. Is there any way to do this or have to do it manually.
Don’t. Migrations are version control for your database. “Removing” a particular migration is like removing a random commit from your Git repository’s history: it can have terrible consequences.
Instead, if you no longer need a table, then create a new migration that drops that table in the up method, and recreates it in the down method so the migration can be rolled back.
Delete the migration file, remove the table from the database, and also remove that file name from migrations table in the database.
Sometimes, doing things manually is the best way.
Just do it manually and save yourself the stress of further issues
Delete the model first (if you don't) need the model any longer
Delete the migration from ...database/migrations folder
If you have already migrated i.e if you have already run php artisan migrate, log into your phpmyadmin or SQL(whichever the case is) and in your database, delete the table created by the migration
Still within your database, in the migrations folder, locate the row with that migration file name and delete the row.
Works for me, hope it helps!
If you simply remove (delete) the migration file and re-run the migrations (migrate:refresh), the database tables will be rebuilt (without the table that's defined in the migration file you deleted).
you can increment the batch number of that particular migration to make it latest batch and run rollback command.
Rollback one specific migration in Laravel
I am having a very bad situation here, working on a Laravel 5 project. previously developed by another developer. That developer at start created couple of tables using migration generators and added some columns using migrations. After that, he added table columns straight away using some sql GUI. I was given the sql dump which i imported and set it up on my local machine, now when i created a table using php artisan make:migration create_myTableName_table --create="myTableName" the table migration is created successfully, but, when i did php artisan migrate it's giving me SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'someTable' already exists I checked migrations folder and matched it with current version of someTable and i can see the columns are different, same with other tables aswell.
What should be the best case to handle this in this situation, i want to keep up with Laravel migrations generator so that in future if any other developer want to work on this project he just has to run migration command to migrate database or to create tables or create columns... Should i re-write all migrations ? pleas help. Thanks
Given your situation, I’d put the .sql export in your repository, clear out the old, broken migrations, and create a new one that initially imports the database dump. Then just create migrations as normal going forward.
Quick and dirty?
Delete current migration files. Clear your migrations table and export the whole DB. Put the SQL dump in the repo and instruct other devs to import it before they run php artisan migrate. With the dump imported and migrations table truncated, you can create new migrations with no further collisions with the legacy migrations.
Feeling ambitious?
Use a package like migrations-generator to generate migrations based on your current DB structure. Then, migrate away.
In my project, current approach is to create database if not already exists using CreateDatabaseIfNotExists and doing seeding initial data from that Intializer as well. I also added Code First Migration support after upgrade to Entity 4.4, so that in the future when we change the modle/database structure we can update client side database without drop their exist database.
However it didn't seems to working well, for example, I am now stuck on design time where forms wouldn't load and the error message is something like The model backing the 'myEntities' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).. But the model and database is indeed the updated version, just seems Migration didn't recognize the database generated by CreateDatabaseIfNotExists, but at the same time all seems working well at run time.
Also after that I noticed that if I let CreateDatabaseIfNotExists initialize a database, Add-migration afterwards will fail and complain that pending migration and ask me to do a update-database. When I try to do a the update-database, it will fail as well because the migration path seems assume the database is in initial setup state and will trying to running all the migration scripts while none should be run as the database generated by CreateDatabaseIfNotExists is indeed sync with current model and should not be migrated at all.
I discovered that there is a MigrationHistory table in System Tables, that table will always save the database initialize history regardless of whether the initializer is CreateDatabaseIfNotExists or MigrateDatabaseToLatestVersion. The difference is that if database is initialized by CreateDatabaseIfNotExists1, everytime the database initialized, the migriationId for that initialize record will be different, butMigrateDatabaseToLatestVersion` will always save same set of migrationId for each of the Migration steps. I guess that is how Entity Framework 5.0 works.
So in the end, I give up and rewrite my DB Access code to seeding the initial database data
in other part of my code rather than the CreateDatabaseIfNotExists or MigrationsConfiguration` class because either suit my need.