We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. Developer Tools

Working with Migrations

I am trying to figure out how to use the developer tools and the migration system. As others have pointed out, it seems problematic to rely on a versioning system like 1.0.0 when working with a larger team as version numbers between developers could overlap. The help for Phalcon Devtools (3.0.1) shows additional options for managing the migrations: --desc=s Migration description (used for timestamp based migration), --ts-based Timestamp based migration version, and --log-in-db Keep migrations in the database table rather than in file.

I have tried using the --ts-based option, but it did not seem to change anything in the way the Devtools handled migrations. I have not been able to find much help on these options in the docs. Has anyone else had any experience with them?

Also, the inital generate call creates a 1.0.0 migration set, but there is no table create code. Does that mean I have to write the table create code by hand?



3.2k

Ok. I've answered part of this myself. I did not catch that Migration::morphTable is a 'magic' method that describes the database state so that when the migration is run, phalcon does whatever is required to get the DB into that state. Therefore, createTable() call are not needed.



5.9k
Accepted
answer

You should probably try to use the developer tools with the branch 3.0.x. 3.0.1 seems to be very unstable regarding migrations.

https://forum.phalcon.io/discussion/14517/migration-generator-creates-an-almost-empty-file

https://forum.phalcon.io/discussion/14795/developer-tools-only-create-indices-and-no-columns



3.2k
edited Nov '16

Just to help with others facing similar questions, I've sorted out how to work with the dev-tools and migrations (at least for my purposes).

NOTE: Switching to the 3.0.x branch did help. I found at least 2 bugs in the master branch that were fixed in 3.0.x (unfortunately, I found them after I had applied my own fixes).

Generate time-based migration versions

To create time-based migration versions make sure you generate your migrations with the --descr=s option. Your description will be used at the end of a generated folder name, e.g. 1479865560862257_init, for your new migration set. If you leave off the --descr option, the default versioning will be used. It is important to realize that you will need to use the --descr option every time you call phalcon migration generate as it will revert to the default reversioning scheme if you don't.

Example: phalcon migration generate --descr=init

Run time-based migrations

To run your time-based migrations, you need to use the --ts-based option on your migration run. Again, you will need to do this every time or the script will complain that it could not find any migrations to run.

Example: phalcon migration run --ts-based

Remember your settings

The documentation doesn't tell you, but you can put some settings into your config file that will make things easier. If you set migrationsTsBased to true, phalcon dev-tools will pick it up and you will not have to remember to include the options every time. While I was happy to find this, it was not posted anywhere in an obvious, easy to find way. I was getting ready to re-invent the wheel when I found it in the code. I currently have this in a config.ini and it seems to work fine:

[database]
adapter  = Mysql
host     = localhost
username = <username>
password = <password>
dbname   = <database_name>

[application]
migrationsTsBased = true
logInDb = true

Of course, you will need to set your databse connection properties for your system. The logInDb option tells the dev-tools to log the migrations in the databse for me. It is equivalent to using --log-in-db on the command line.

I hope this helps others avoid some unnecessary woes :-)