Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ran migrate instead of baseline, got error; now can't run baseline because of history table #2527

Closed
kippm opened this issue Oct 8, 2019 · 6 comments

Comments

@kippm
Copy link

@kippm kippm commented Oct 8, 2019

Which version and edition of Flyway are you using?

6.0.4, community edition

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

Command-line

Which database are you using (type & version)?

SQL Server 2016

Which operating system are you using?

Windows 10

What did you do?

First I tried a migration, which failed, because I didn't create a baseline before. After that I ran the baseline command.

What did you expect to see?

The baseline should be stored. This worked like that in version 5.2.4

What did you see instead?

Baseline not stored in the table.

@juliahayward
Copy link
Member

@juliahayward juliahayward commented Oct 10, 2019

Could you send us an anonymised version of the migration script which failed? I don't understand why the presence or otherwise of a baseline would affect a migration.

I've tried with both 6.0.1 and 5.2.4 and both will fail to baseline if migrations have already been performed. The intent is that baseline creates a marker in an existing database that Flyway has not previously been used with, to prevent old and unnecessary migrations from being wrongly applied, so once you have run migrate a baseline is no longer required.

@kippm
Copy link
Author

@kippm kippm commented Oct 10, 2019

The problem is not related to the migration. To reproduce what I meant, then just take an empty database and run a baseline. Then delete the only row from the flyway table and run the same baseline again.

I would expect that the baseline would add one row to the flyway table, but it doesn't. The flyway table stays empty.

With 5.2.4 it just works as expected.

@juliahayward
Copy link
Member

@juliahayward juliahayward commented Oct 10, 2019

OK, thankyou. So the specific problem is that because the migration failed, it left an empty schema history table which could then not be baselined? If that's so then I understand the problem now. We will need to carefully consider a behaviour change, as a migration could potentially fail part way through and a subsequent baseline might be misleading.

@kippm
Copy link
Author

@kippm kippm commented Oct 10, 2019

Yes, you are correct. And as stated, this behavior was different (and according to me correct) in 5.2.4.

@alextercete alextercete added this to the Flyway 6.2.0 milestone Nov 5, 2019
@juliahayward juliahayward changed the title Baseline command doesn't work when the flyway_schema_history table already exists Failed first migration leaves behind empty schema history table Dec 5, 2019
@juliahayward juliahayward changed the title Failed first migration leaves behind empty schema history table Ran migrate instead of baseline, got error; now can't run baseline because of history table Dec 5, 2019
@MikielAgutu
Copy link
Contributor

@MikielAgutu MikielAgutu commented Feb 24, 2020

@kippm You say:

The problem is not related to the migration. To reproduce what I meant, then just take an empty database and run a baseline. Then delete the only row from the flyway table and run the same baseline again. I would expect that the baseline would add one row to the flyway table, but it doesn't.

Manually altering the schema history table is likely to cause Flyway to enter an inconsistent state. Therefore we can't really support workflows that involve such manual alterations.

In this scenario, you've manually altered the schema history such that it's empty. In this case the Baseline command doesn't do anything. I think this is the correct behavior. All you need to do is run clean, or manually delete the schema history table, and run baseline again.

As much as it is a behavior change between Flyway versions it doesn't seem particularly significant to me.

@MikielAgutu
Copy link
Contributor

@MikielAgutu MikielAgutu commented Feb 24, 2020

Actually we'll make baseline produce an exception in this case to make it more clear that baselining an empty schema table is invalid.

@MikielAgutu MikielAgutu removed this from the Flyway 6.x milestone Feb 24, 2020
@MikielAgutu MikielAgutu added this to the Flyway 6.3 milestone Feb 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants