Migration cache should stored in database.

[robinlehrmann]

Hi,

very cool project! But I have one problem:

I have shops in multiple environments: development testing staging production

Each environment has it's own database and my deploy software (http://typo3.org/additional-products/surf/) restore the current live database and create a new installtion of the shop:

releases/201410011000/ releases/201410012000/ releases/201410013000/ releases/201410014000/ releases/201410013000/previous -> releases/201410013000/ releases/201410014000/current -> releases/201410014000 <- thats active the root dir of vhost

The problem:

I deploy a new feature with new database tables and columns but the deployment restore the database. The columns and tables are deleted. Now I run "oxid migrate" and all migrations are executed.

So I think a table is the best solution to resolv this problem.

It would be nice to have this features:

• commands and migrations in modules.
• oxid-console as real oxid module with composer compatibility.(put "oxid" in composer bin-dir and symlink "oxid" in the source dir and put the functions.php contents in "oxid") https://getcomposer.org/
• setup command to install via shell

If you want I could create some pull-request for it.

Cheers, Robin

[ellisv]

Saving migration status in database might be not a bad idea. Will think about it.

I've got big plans for new oxid console version to have it as a standalone application which bootstraps oxid inside.

[ellisv]

Migration statuses are already stored in database with a pull request #21