Flyway after a certain time marks old scripts that have already been applied as new and in Flyway Info marks them as ignored. In the end, nothing applies.
This is my flyway migrate:
This is the flyway info:
In red, you could see the last script applied without issues.
In 'blue' you could see that flyway listed old scripts like "Are not applied".
Do you have any idea, why this is happening?
I am using Flyway community edition license.
Related
I have recently started using the baseline and repeatable migrations in my app. Although I don't seem to be using any teams-edition features, yet flyway somehow switches automatically to the Teams edition instead of Community edition, and shows a message :
Flyway Teams Edition 8.2.0 by Redgate
Flyway Teams features are enabled by default for the next 27 days. Learn more at https://rd.gt/3A4IWym
Previously we had eight versioned migrations V1__xxxx.sql to V8__xxxx.sql
Now we have made the following changes :
All the eight migrations, plus some other init scripts have been combined into a single migration V1__seed-data.sql
Repeatable migrations have been put into R__xxxx.sql
Some placeholders have been placed into the flyway.conf like : fileflyway.placeholders.app_db_name=${APP_DB_NAME}
For our existing Production DB, which was already migrated till V8, we have Dropped the flyway_schema_history table and used the "flyway baseline" command with an environment variable FLYWAY_BASELINE_VERSION=1
After this, the flyway_schema_history shows us this result :
But after these changes, we are seeing the "Teams edition" message as above.
Earlier it used to show :
Flyway Community Edition 8.2.0 by Redgate
I am quite sure looking at the flyway documentation that we haven't used any Teams edition features. https://flywaydb.org/documentation/usage/commandline/baseline
Now I have 2 questions :
What caused flyway to switch to Teams edition without teams features being used?
What happens once the trial period ends? Does flyway block all our migrations in the future unless we buy the license?
Update Flyway to the latest version; the "Auto trial" feature created the "Teams edition" message you're seeing here, and was removed in Flyway 8.4.3 - release notes.
I changed a flyway script for error, and this brought my migrations to an error state (I have 5 script versions, but when I run my app it starts from the 4th, and get an error on 'reaction already exists').
I tried to use clean from flyway cli, but it didn't completely solve the problem... also, when I try pushing my branch to git, CI/CD pipeline will fail for the migration.
Since I'm in development environment, would it be a terrible idea to all delete migration scripts?
Would deleting all scripts allow me to 'start from scratch' in my development environment, or do I need to push the whole project again to avoid issues? (Project is not in production yet, I don't really need flyway migrations)
Depending on which flyway version you are using, one option is to go to the flyway_schema_history or schema_version table and just locate the row (corresponding to the failed script) and change the success column to true or 1. Then manually run the script (the correct one) against DB.
We have a customer with a IT-department that insist on getting database updates as scripts prior to upgrades (they want to "read" the updates before implementing them).
Being an avid user of flyway it made me think about a way of generating a script from flyway based on updates and send this script to IT. This script would at the very least need to create version table if non-existant, check version and apply needed updates. It would of course be proprietary to database vendor (in my case Oracle).
This would allow us to run updates with flyway automatically in development environments and create manual scripts for test and production.
Are anyone aware of something like that having been contemplated or endeavored before? Would it be trivial or a momentous task?
We had this exact problem when I worked at a consultancy (Intelliware) so the devs there put together some code and pushed it up to GitHub.
We tried unsuccessfully to get it included into the Flyway core repo.
https://github.com/Intelliware/flyway-script-generator
I looked at the Flyway samples and documentation and tried to understand if it is useful in my environment.
The following conceptual detail is unclear to me: How does Flyway manage the changes between database versions? It obviously does NOT compare database life-instances (see answer here:Can Flyway find out and generate migration files from datamodel?)
In detail my setup looks like this:
I create SQL create and insert scripts when coding (automatically and manually). This means every version of my database is represented by a number of insert/create statements.
In my world I execute these scripts through a database tool (sqlplus from Oracle). Each run would setup the database _from_scratch_ (!).
Can I put these very same scripts 1 to 1 inside the "migration" path of Flyway? What happens if the target database is way older than the last "migration step" I did (or flyway did not yet exist when it was installed)?
Update:
I got some input from another Flyway user:
It seems like each "migration" (version of the database) has to be hand-written SQL/Java code and contains only "updates" from the previous "migration" of database.
If this is true, I wonder how this can be used with traditional coding technics: in my world SQL statements are generated automatically and contain all database init/create statements, not just "updates" to some previous version. If my SQL code generator could do that, then I wouldn't even need a tool like Flyway :-).
Your question about "how to handle a DB that has a longer history than there are migration scripts?" You need to create a V1_ migration/sql script that matches/recreates your latest DB schema. Something that can take a blank DB to what you have today. Create/generate that sql script using your existing DB tools and then put it in flyways migration directory. (And test V1 by using flyway against a clean DB and see if you get what you expect.) http://flywaydb.org/documentation/existing.html
After that point in time, all later versions must be added in as you work. When you decide you need a new table, in your dev environment, write a new V*_.sql that modifies your schema to the way you need it.
This blog goes over this situation for a Spring/SQL application. https://blog.synyx.de/2012/10/database-migration-using-flyway-and-spring-and-existing-data/
OUR SYSTEM
We are trying to put migrations as .sql files under version control. Developers would write a VN__*.sql file, commit to version control and a job that runs every 5 minutes would automatically migrate to a Dev and Test database. Once the change proved to not cause problems, someone else would run a manual job to run the migration on Production.
MY PROBLEM:
I had a demo migration that created a few tables. I checked V4__DemoTables.sql into version control on my PC.
On our Linux box a job that runs every 5 minutes extracted the new file from version control, then ran the flyway.sh file. It detected the file and executed it.
But the .sql file had a typo. And we are using Neteeza which has problems with flyway automatically wrapping a migration in a BEGIN TRAN ... END TRAN. So the migration created 2 tables, then aborted before the third.
No problem I thought. I dropped the 2 tables that the .sql file did create. Checked V4__ out of version control, fixed the typo and re-submitted it.
Five minutes later the update was extracted but flyway complains that the checksum does not match. So it will NOT run the updated V4__DemoTables.sql file.
How do I get flyway to accept the updated file and update the checksum in the SCHEMA_VERSION file in case of a typo?
Reading the docs it seems like the developers suggest I should have created a new V4_1_DemoTables.sql file with the fix's. But this would have collided with the commands in the V4__ file so this seemed wrong.
So here is what the docs imply I need to do:
Leave V4__ as a 'successful' migration according to the
SCHEMA_VERSION table.
Create V4_1_ to delete the tables that were created before the typo
line in V4__.
Create V4_2_ which has the typo fix from the original file to do all
the real work.
Is this correct?
If the migration completes successfully, but some of the db objects are not quite right yet (typo in column name, ...), do as you said and push a follow-up script that fixes it (rename column, ...).
If the migration fails, and it didn't run on a DB with DDL transaction, the DB must be cleaned manually. This means:
Reverting the effects of the migration on the DB
Removing the version from the SCHEMA_VERSION table and marking the previous one as current
This second step will be automated in the future with the introduction of the flyway.repair() command.