Running Phinx migrate a second time does not update the database with the new migration

I've created the following migration. It works the first time I run it, but if I make changes to the migration - such as adding a new column - when I run phinx mingrate -c src/phinx-config.php it doesn't update the database.

It appears to do nothing. If I delete the entry from phinxlog in the database, and remove the user table it will recreate the table. Otherwise, no changes are made.

If I delete the entry from phinxlog and don't delete the table, I get an error that the user table already exists. I though this was the purpose for down() so it can drop the table?

Here's my code:

<?php

use \StudentApp\Migrations\Migration;

class AppMigration extends Migration
{
   public function up()
   {
       $this->schema->create('users', function(Illuminate\Database\Schema\Blueprint $table) {
           $table->increments('id');
           $table->string('firstname');
           $table->string('lastname');
           $table->string('email');
           $table->string('password');
           $table->string('token');
           $table->timestamp('token_expiry');
           $table->timestamps();
       });
   }

   public function down()
   {
       $this->schema->drop('users');
   }
}

Any ideas why the database isn't being updated when I rerun migrate?

Phinx (and most other migration libraries) doesn't inspect each migration for changes. Phinx looks to see if the timestamp at the start of the filename is listed in the phinxlog table, and if it doesn't exist yet, then Phinx will run the migration.

So, when you run migrations for the first time, Phinx will find 20161123122600_app_migration.php in your migrations folder and it will run the migration's up method and apply the changes there. It will then add 20161123122600 to the log. Because the next time you run migrate, Phinx will see that 20161123122600 already exists, it will just pass over to the next one.

The point of all this is that once your migration is in version control, you shouldn't be changing the migration (other people may have used it and will have the same problem that you experienced if they check out a new version of a migration that has already been applied). The best thing to do, especially if the migration has been pushed or merged, is to create a new migration that modifies the existing table (and include a rollback that reverts the change).

If you haven't yet pushed the changes, then you could rollback your migration (which will call the down method) and then add the new column and rerun the migration. You should then squash the commit so that people can't checkout the unmodified migration. All in all, it would simply be easier to create a new migration for this change.