You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using flyway 7.0.0 and mysql 8.0.25, when I tried to create sql and reverse sql to be executed by flyway, I did the complete opposite. So first time the execution failed and there's a fail execution history log in database table 'flyway_schema_history'.
Then I reversed the content of the two sql files and recommit, expecting to execution again for the last execution log is tagged as fail. However, the sql file did not be executed by flyway just because this version have been executed (even if the execution was actually failed).I seached on Internet and the solutions are just delete the failed history or update the filename to update the version. That's not a good experience.
I agree that we should not repeatedly execution sql when it was executed successfully and should create new sql file to do afterwards operations. However, when flyway check if a sql file was executed, shall we considered if it was executed successfully instead?Yeah , I mean check if the latest execution history log success=1.
ps : I readed the latest source code and I'm suprised to see that if a sql version was executed failed , flyway will return a fail state and immediately throw a FlywayValidateException in Flyway.migrate() method. Is it an operation to force developers to delete the failed history in database or update a new version? I don't think that's a good choice. May be a repeated execution on the failed version should be allowed even it is not marked as repeatable?
The text was updated successfully, but these errors were encountered:
I'm sorry that I can't change the unified version used in our company. However, as I mentioned before, the latest source code shows if a sql version was executed failed , flyway will return a fail state and immediately throw a FlywayValidateException. In other words, there's similar issue with the latest version of Flyway.
We are using flyway 7.0.0 and mysql 8.0.25, when I tried to create sql and reverse sql to be executed by flyway, I did the complete opposite. So first time the execution failed and there's a fail execution history log in database table 'flyway_schema_history'.
Then I reversed the content of the two sql files and recommit, expecting to execution again for the last execution log is tagged as fail. However, the sql file did not be executed by flyway just because this version have been executed (even if the execution was actually failed).I seached on Internet and the solutions are just delete the failed history or update the filename to update the version. That's not a good experience.
I agree that we should not repeatedly execution sql when it was executed successfully and should create new sql file to do afterwards operations. However, when flyway check if a sql file was executed, shall we considered if it was executed successfully instead?Yeah , I mean check if the latest execution history log success=1.
ps : I readed the latest source code and I'm suprised to see that if a sql version was executed failed , flyway will return a fail state and immediately throw a FlywayValidateException in Flyway.migrate() method. Is it an operation to force developers to delete the failed history in database or update a new version? I don't think that's a good choice. May be a repeated execution on the failed version should be allowed even it is not marked as repeatable?
The text was updated successfully, but these errors were encountered: