[IMPROVEMENT IDEA] - short index instead of migration timestamp

[tkivisik]

Problem:

• command line autocomplete is tedious with the current long timestamps. Especially when the migrations were created only seconds apart (with a script).
• filenames are unnecessarily long. It means there is less meaningful content displayed whenever filenames are involved, e.g. in gmig as well as here in GitHub ( https://github.com/emicklei/gmig/tree/master/examples )
• timestamp serves no further purpose than ordering of migrations. For example, migration A could be updated after many more migrations B C D have been added. Timestamp therefore can't be seen as 'last edit' time nor as a 'time of creation' as D could be made to run earlier than A by changing D's timestamp.

Proposed solution:

• Replace the current long timestamp with a short index instead (e.g. 01).

Benefits

• autocomplete is easier - one keystroke to narrow our search to 10 migrations, two keystrokes to a unique migration. The unique characters are also at the beginning of the filename, making it easier to read and find them.
• more space is left for meaningful content of the migration.
• until convenience functions are written to allow inserting a migration immediately after some existing migration, indexes could be added with a gap in between (01, 04, 07, 10 etc)

[Ernest Micklei]

Thank you for these comments and suggestions.
I understand and agree with the problem stated.

We need and therefore will change the naming convention for migrations.

[Ernest Micklei]

As (our) projects typically have > 10 migrations and we want to have "gaps" in the names, I propose:

010_create_service_account_gopher.yaml
020_set_permissions_to_gopher.yaml
025_forgotten_migration_to_run_before_30.yaml
030_create_bucket_for_gopher_greetings.yaml

[Ernest Micklei]

If the folder contains existing 2 migrations using the "old" name format then 030_next_one.yaml will not have the right index in the order list of migration files.

030_next_one.yaml
20180305t144044_create_database.yaml
20180305t144109_create_proxy_service_account.yaml

When prefixing new migration files with the "new" name format, it can be solved:

20180305t144044_create_database.yaml
20180305t144109_create_proxy_service_account.yaml
_030_next_one.yaml

One can also decide to rename all files but that also requires to forcefully change the last migration state.

[tkivisik]

Good point. I feel always writing a prepend (e.g. underscore) would be a long-lasting change. When a person starts using gmig after the update, they would have all their migration files starting with an underscore even though they don't know the reason for it.

How about solving the same problem with an if statement: if there are any files starting with a timestamp (as it is currently) in the main directory, then prepend something greater than 2. I would propose prepending '3' instead of an underscore, as it would be even less prone for edge cases like the times when that folded also includes files starting with a number e.g. 4, 5 or 6. When there is no files starting with a timestamp, then go embrace the new cleaned naming convention 010... 015..., 020... etc.

[Ernest Micklei]

so what would the next filename be?

20180305t144044_create_database.yaml
20180305t144109_create_proxy_service_account.yaml
300_next_one.yaml
310_last_one.yaml

[tkivisik]

Yes, the next ones should be as in your example. Also, it might be best to write an updater function, which would:

1. When there are migration files with the old convention
2. Get the state of all projects
3. Start renaming based on the index - first file to 010, then 015, 020
4. Update project state when renaming to a new one
5. Keep a log of changes

[Ernest Micklei]

kind of like a "go vet".

gmig vet migrations [configpath]

later I need

gmig vet config [configpath] for the anticipated JSON -> YAML.