Add a 'new' command

[jamlen]

Just wondered if others would find this useful...

I'd like to see a new command so when using the command line I can do

sql-migrate new udf-ParseDate

and it create a templated file in the ./migration folder (or what ever this is set in the config) named <current epoch>-<name>.sql, eg: 1443610373-udf-ParseDate.sql

The templating would have the -- +migrate Up and -- +migrate Down defined.

An enhancement to this would be to take the name and scan for the last migration matching the name and populate the migrate Down section of the template from the last migrate Up script.

Comments appreciated, if people like this I'll look at PR.

[rubenv]

One thing I didn't want to enforce is a naming convention for migrations (the prefix). You can use the epoch, some kind of formatted time stamp or a sequence number; you can separate it using dashes or underscores: all these options are perfectly fine and valid, it's just a choice you make for your project.

I'd love to have a new command, but we'll need to find a way to avoid pushing people into a fixed pattern.

If we can figure that out: yes please!

[jamlen]

OK so how about we have a way of specifying the format in the config or use the default? Options could be

• epoch - default
• iso for ISO-8601 datestamp
• counter which increments count of current folder listing
• none

Also I would like to append the action so to expand on my example above:

sql-migrate new udf-ParseDate alter

results in ./migrations/1443610373-udf-ParseDate-alter.sql

If action is create then the pre-population of the migrate Down would be skipped, but for alter or drop it can do the scanning thing and populate it.

[rubenv]

If action is create then the pre-population of the migrate Down would be skipped, but for alter or drop it can do the scanning thing and populate it.

How would that work?

OK so how about we have a way of specifying the format in the config or use the default?

Can we be smart about it and detect the used style from existing migration files?

[jamlen]

How would that work?

As an outline, it would:

1. use the name and find all the migrations that match in the filename.
2. establish the latest one
   • which should be sort filename descending, take the first.
   • If none was chosen that might be tricky or unreliable as it would have to rely upon modified date.
3. Read that file, find the -- +migrate Down
4. Insert into template

Can we be smart about it and detect the used style from existing migration files?

We could do, so look at the first & last file and use regex to work out the format. Personally I'd rather use the config file rather than trying to be smart (KISS principle). At the end of the day, this would only affect the new command usage.

[rubenv]

Personally I'd rather use the config file rather than trying to be smart (KISS principle).

I guess we have different opinions on KISS then :-). Any piece of configuration we can avoid is a net win, but if the alternative is something that barely works, sure.

[doctordesh]

One thing I didn't want to enforce is a naming convention for migrations (the prefix). You can use the epoch, some kind of formatted time stamp or a sequence number; you can separate it using dashes or underscores: all these options are perfectly fine and valid, it's just a choice you make for your project.

Is it bad to use a default prefix if you allow them to change the prefix-pattern in the config? I personally have always used the YYYY-MM-DD-HH-II-SS pattern but a sequence number or epoch would work just as good. Personally I would not think it's bad to choose a default and then just let the config decide.

Do you feel that you are enforcing them when choosing a default that can be changed in the config?

[codepushr]

I'd find this quite useful. I'd also make sense because incrementing the prefix by hand doesn't work in big teams where people create migrations simultanously and creating a timestamp by hand just feels weird. Many modern migration cli tools offer a create sub command. Good idea!

[rubenv]

Thanks to the wonderful work of @yageek, there's now a new command.

It's not configurable nor smart, but we had to start somewhere. If someone is willing to make this format configurable and/or smart, feel free to join in!