Fail validate if an already applied migration couldn't be found #988
Comments
+1 We've ran into this issue as well, which in our opinion could also be a bug, because the behavior of
but
Calling I'd be happy to provide a pull request to implement this issue, if needed. |
+1 We are experiencing the same problem. Should we trigger a manual validation before or this will be fixed? |
+1 This could be quite a serious issue. We don't know whether a file is legitimately missing or accidentally removed so at the point of deployment should be alerted that a file we've already applied is no longer present |
+1 |
1 similar comment
+1 |
+1 |
1 similar comment
+1 |
Fixed. No new config option. Missing migrations now always trigger an exception. |
@axelfontaine Is there no way to skip this check?
|
@davidkarlsen You can either set |
We are using for every featrue a new branch, so it appears, that the following situation appears: Branch 1 has migration script "V20160317_1__Unique_User_Names" So, if I started in Branch 1 everything is alright. Ich I switch to Branch 2, I will get this Error: The only chance I have is to NOT validate or using version 3. Is there a way, to handle this in version 4? |
I am facing the same issue.
+1 |
Same problem here on v4.0.1, |
Checked again on v4.0.3 and the validateOnMigrate=false does not prevent the error:
Should we fill a new bug report ? Thanks, |
@AndreiArion Yes, please open a new issue with all the relevant details on how to reproduce this. |
These needs to be controlled by a configuration option!! This requirement assumes that schema updates are all handled by one repository and process. That's just not realistic! In our shop, we have so many projects that all feed in to each customer's databases, depending on what modules they license. Each module, has it's own specific schema update necessary to make that module work. They all need to co-mingle, and turning off the validateOnMigrate feature just won't cut it. Migrations still need to be validate in case we start to use the new Repeatable option or if an older Validated migration is changed by mistake. With this new requirement, we're stuck at 3.2.1... :( |
@AndreiArion It appears @pik0 was faster and opened #1352 |
Yeah, the powers-that-be were breathing down my neck for answers. Had to revert back to 3.2.1 and advise them of the status. Decided to file the bug since I already had gathered the report for them. Looks like this won't be fixed until 4.1 at the earliest based on other issue reports I'm seeing... :-/ |
Hi, I getting below error while running spring boot with flyway and postgres sql. Any one can please help on to fix this issue, Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Validate failed: Detected resolved migration not applied to database: 1.0 Thanks and Regards, |
Could you please guide on http://stackoverflow.com/questions/23776706/flyway-3-0-migration-checksum-mismatch ? |
Validate currently fails if the hash of a applied migration differs from the hash of the same migration found in the classpath. However, it doesn't fail if the applied migration could not be found on the classpath.
I would like to see an option for this. Actually I thought that would be the default behaviour, so I would even suggest to activate that option per default, maybe in the next major release.
The option would help in cases where:
Related stackoverflow question:
http://stackoverflow.com/questions/29541845
The text was updated successfully, but these errors were encountered: