Migrations with fixed timestamp

[ndeblauw]

Synopsis:

I'm using blueprint to speed up my development workflow, and it's really great for this. At the start, I especially liked it to make changes in the draft.yaml and then rerun the whole thing. And check the effect of the changes and learn from that. Getting confidence in the tool etc... I used this handy oneliner for this

php artisan blueprint:erase && php artisan blueprint:build && php artisan migrate:fresh

Once the models kind of felt right as a basis to start on, I extended some of them a bit, edited some of the other files and wrote some more custom stuff. Important changes I of course adjusted as well in draft.yaml. To keep track of everything, I committed everything it to git.

Then I returned back to my draft.yaml and wanted to start working on the controllers section in the same iterative way as before. This works for everything, except for the migrations.

I can easily track my customisations (e.g. to factories, to the models) because of git. But this is not the case for the migrations, as their filename depends on the moment they are created. Which makes it a bit of a pain to track the differences as soon as you go above 10 tables.

I'm fully aware blueprint is for fast prototyping, and that the use case I'm describing is a bit differing from the initial thought. But prototyping on the other hand is an iterative process where you learn by doing and adjusting and pivot around your requirements. And to be sure not to loose work/overview or to be able to share with others, git is an essential part of this workflow.

Proposed Syntax:

Not really sure which way forward to recommend.

• Maybe a flag for blueprint:build --reusetimestamps that makes migrations keep the original timestamp in their name. But then again, I have no clue where (and if) you would store that kind of information, and how diffi
• Maybe a flag for blueprint:build --fakedatemigrations 2020-06-11 20:00 that gives migrations a fake date (e.g. the one specified) and than adds a second for each migration that is created in the order they are specified in the draf.yaml file.
• ???

Expected Behavior:

Migrations with a constant (consistent) timestamp so that tracking differences with version control becomes easier/possible.

[jasonmccreary]

If it were me, I would just delete the migrations and rebuild them with Blueprint. Git should see them as a rename and preserve the history.

With that said, I am not opposed to an --overwrite-migrations option. I think that would fit your use case as well as other use cases (such as projects which want a single migration per table).

I'll tag this with community for anyone to pick up. It would likely require some logic in the MigrationGenerator to see if a file of _create_xxxx_table.php existed and if so, overwrite it instead making a new one. Ideally being noted in the updated output list.

[ghostwriter]

@jasonmccreary does #319 resolve this issue?

[jasonmccreary]

Indeed. Must not have been tagged in the PR properly. Thanks!