[up-to-date] print the names of executed unavailable migrations

[dbu]

Q	A
Type	improvement
BC Break	no
Fixed issues	-

Summary

I was confused why the up-to-date command does not tell which migrations are missing. From the logic in this command, we can't tell so at least we can point to the status command which will output that information. As we have the list available, print it.

(Looking at the code, there is a scenario where i have an additional migration that should be done, and have a migration in the database that has been deleted in the filesystem. If those 2 numbers are the same, the up-to-date command will incorrectly state that all is up to date. This should be improved but i consider it out of scope for this small improvement here.) (i had been looking at an outdated version of the command)

[goetas]

Hi!
$executedUnavailableMigration contains the list on unavailable migrations, does it make sense to list them already here or just to redirect users to use the status command?

[dbu]

in our project we use an old version of doctrine/migrations, that confused me into writing all these comments - sorry. i now simply print the list of executed unavailable migrations. does that make sense like this? (i decided to go shorter than the migrate command which lists a line for each such migration, and prints the date if available - if you think i should do exactly the same as there, i can adjust it)

[dbu]

fixed the code style issue

[goetas]

The list of unavailable migrations could be quite long.

Another point is that we have already a command to list the not available migrations migrations:status --show-versions... my question here is: is this the right command to show again the list of missing migrations?
Considering that we are already displaying the count of them...

@dbu I'm sorry for making you work in advance, I should have raised my concerns before...

[dbu]

we use the migration up-to-date check in our CI. it would be convenient to not have to log onto the server and run another command (and having to figure out what command to run) to see what migration the status command is talking about.

my original PR was making the message at least print the name of the other command you need.

if your concern is mainly the length of the list, i can also print just the first 3 or so, and then say "and X more." if there are more than 3. i guess there is essentially 2 cases: somebody tinkered with migrations and one file somehow was removed after having been run, or no migration files have been found. in the first case it would be helpful to see the migration(s) so you can check what happened with that one. in the second case printing does not help - you need to fix something to make migrations see the files again, or truncate the migrations_versions table because you rolled up all migrations into one file or something like that.

[goetas]

Your motivation convinced me!

Regarding the "long list of missing migrations": what about using a Table as in

migrations/lib/Doctrine/Migrations/Tools/Console/Command/StatusCommand.php

Line 101 in 3e4b0c8

private function showVersions(

?

[dbu]

haha, and your worry made me realize that the full list is unlikely to ever be useful. i'd rather cut off after 3 versions. would you agree with that?

[alcaeus]

• Using an extra command for this can certainly be helpful
• The list can cary depending on the verbosity setting, e.g. nothing on --quiet, up to 3 or 5 migrations by default, and full list on -v. WDYT?

[goetas]

I would suggest to display all the missing migrations, but only if some extra option is specified as suggested by Andreas. Without that command will keep the output as it is

[dbu]

@alcaeus @goetas so which should it be? i like the suggestion of @alcaeus better - okay if i adjust to that?

[goetas]

I'm not sure if an extra command here is the solution... we have already maybe too many of the.
What should this command be named?
Consider also that I plan to implement #734 in v3, maybe it can be just displayed there?

[dbu]

ups sorry, i misread the suggestion. i was thinking of keeping it on the up-to-date command, but doing the verbosity thing as alcaeus proposed.

i agree that we should not add more commands for this.

my use case is that an automated check would immediately print what is wrong, instead of only that "something" is wrong. for that use case, the output would need to be on the up-to-date command. if you think its not worth having that, i have no problems if you refue this pull request - i consider it useful, but its not super important as i can run the status/list command after seeing the failure.

regarding number of commands, you could have status --check or something like that and deprecate up-to-date, but that would be implicit and contrary to creating that new list command.

[goetas]

I think that this PR adds value, so I would like to see it implemented.

I'm just concerned if is worth having some --quiet option to display more or less stuff. I would just place a Table with all the missing migrations, and that's it. Less options and special cases we have to manage, the better.

[alcaeus]

I can live without a quiet switch - this can always be added in the future if necessary. 👍 from my side.

[goetas]

alternative draft in #917

[dbu]

closing in favor of #917