'new' should not require dbconfig.yml

[tobischo]

trafficstars

As far as I can tell the new command only creates a file with the correct format. For that the -config and -env flags should not be required, since it does not have to speak to the database. https://github.com/rubenv/sql-migrate/blob/79fe99e24311fa42469fb2ca23eb3f8f065e6155/sql-migrate/command_new.go#L36

I'd suggest removing the requirement to provide these options as they are not relevant for this case.

That would also open up using sql-migrate new <name> locally without requiring the dbconfig.yml

An example use case: We are using sql-migrate with embedding everything so that we have one less dependency on the server where we want to install the application. We also don't use yml files for configuration but rather environment variables. Requiring the dbconfig.yml as the only configuration option for the new subcommand prevents us from using the sql-migrate cli tool locally

[stephen-kruger]

but it needs the parameter dir: databases/mysql to figure out where to place the empty migration template. Why would you use sql-migrate at ALL in this case? Simply copy a file using a basic bash script to generate the empty file.

[tobischo]

For our use case simply because we have more than just one repo and that bash script would have to be copied everywhere. Furthermore adding a bash script would also require to making sure that the latest version of sql-migrate did not change the file format in a backwards incompatible manner. Using sql-migrate on the dev machines would help get around that and not having to have a config file that isn't used for anything else (so we don't need sql-migrate on every server) would be the best case scenario. Therefore I suggested allowing to use environment variables as an alternative option, so that dir: databases/postgresql would be available for placing the file correctly. However I am not sure if anyone else actually matches this particular use case...

[stephen-kruger]

I agree the .yml is a pain to use, it should be possible to pass everything on the command-line. We also use a monolithic repo with multiple sub-projects, and having so many (mostly identical) .yml files is problematic. We have another problem - we don't use the timestamp for naming, as it's hard for humans to easily see the execution order, so we use 000001-something.sql 000002-else.sql etc, but the "new" command doesn't care, or even look at the existing naming, and blindly generates a timestamp based template. :(

[rubenv]

we use 000001-something.sql 000002-else.sql etc, but the "new" command doesn't care, or even look at the existing naming, and blindly generates a timestamp based template.

May have said this before, but I'll gladly accept a PR that detects the naming scheme in use and adapts to that.

[kswope]

I agree with @tobischo , for those using this package as a library it seems surprising that the tool doesn't at least generate a properly formatted and named migration file for them. The missing information could be supplied with cmd line switches and defaults

My workaround, if anybody came here looking for a copy-n-paste solution:

I already use the build tool https://github.com/go-task/task

Here is my task to create a migration file

 "migration":                                                                                                   
    desc: create a new migration file                                                                            
    cmds:                                                                                                        
      - mkdir -p migrations                                                                                      
      - touch {{.FILENAME}}                                                                                      
      - echo "-- +migrate Up" >> {{.FILENAME}}                                                                   
      - echo "" >> {{.FILENAME}}                                                                                 
      - echo "-- +migrate Down" >> {{.FILENAME}}        
      - echo "" >> {{.FILENAME}}                                                                                                                                          
    vars:                                                                                                        
      FILENAME:                                                                                                  
        sh: date +"migrations/%Y%m%d%H%M%S.sql"