Alerts

@ulferik Hey.

It seems like you already have the roles table created and your migrations table does not have the migration that migrates the roles table and hence trying to run that create_roles_table migration and you get that error.

If you already have production data in your database, I believe the only solution would be to manually insert a record to the migrations table:

DB::insert('insert into migrations (migration, batch) values(?, ?)', ['your_roles_table_migration_file_name_without_extension', 1]);

The batch should preferably be one above the max batch currently presented in that table

A good idea, but there are several migrations together in one migration. I don't understand why just one table out of four is a problem with.

I use Workbench and I suppose that I have recreated the roles table in Workbench afterwords. The solution would be to reset the migration and in that process loose all data.

Suppose I have to live with these messages :(

Thank's

@ulferik You don't have to... I don't know how you ended up in that situation but you can easily solve it if you just manually add the record to the migrations table.

I did that but it didn't solve the problem. Used Workbench to add a post in the migration table. The original migration was entrust_migration with 4 tables. three of them is no problem, about the forth "roles" I suppose I have removed it and recreated it in the Workbench. The best thing was to reset and migrate again but it is difficult to repopulate the tables afterwords. They are connected to each other in different ways.

I am new to laravel and must have done something wrong in the publishing process.

@ulferik it shouldn't be too hard to backup your DB, re-run the migrations and then re-populate the database if you can afford a few minutes of website shutdown.

First, let's export the database's data only:

$ mysqldump -u [user] -p[pass] --no-create-info my_db_name > ?~/my_db_name.sql

This will create a data backup of your database in your home directory (~).

Second, we will safely remove the DB and re-create it:

$ mysql -u [user] -p[pass]
mysql> drop database my_db_name
mysql> create database my_db_name

Third, Run the migrations:

$ php artisan migrate

Fourth, re-populate the database:

$ mysql -u [user] -p[pass] my_db_name < ~/my_db_name.sql

mysqldump disables the foreign key check before importing and re-enables that after importing. You can see that by viewing the dumped data file (my_db_name.sql) somewhere in the first lines:

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

I have an RDS in Aws with an old database from 2008 and this new one for the laravel app. The app is for registering work-hours for a chain of shops and the head office. The app was made by CodeIgniter and I am now refactoring it in Laravel. For a start I have made it work for the office-workers and at the moment extending it for the shop-workers. I think I have gone about all of this in the wrong way. I see your point but I am afraid that I will mess everything up.

@ulferik well that sucks :/ I can't suggest anything else unless I familiar myself with your database's schema and app

Thank's @kfirba.

I started working on this app in 2005 with a simple form to mail. Now it has grown a lot and my skill isn't good enough.

I have your solution in mind and if some Sunday morning I feel the strength.....!

@kfirba I have updated the schema in AWS. It was different to Vagrant mysql in the way that string 255 was to long. Had to change strings but now it's OK.

Must say that Workbench is fantastic.

Thank's for pushing me to do this.

@ulferik Sure mate :)

It's always terrifying changing anything in production but sometimes we just have to take the risk and get it over with.

Also, yea, Laravel now uses utf8mb4 as the default character set so it can also support emojis. This makes the maximum string length to be 191. You can just add this to your AppServiceProvider:

public function boot()
{
    Schema::defaultStringLength(191);
}