fix: ignore applied migration checksums via config #67
Conversation
📝 WalkthroughWalkthroughThe changes add explicit versioning for the Lombok dependency, introduce configurable Flyway behavior to conditionally ignore applied migration checksum mismatches via a new property, refactor Flyway bean configuration with a centralized helper method, and provide database datasource configurations for local development environments. Changes
Sequence Diagram(s)(omitted — changes are configuration/refactor and do not introduce a new multi-component sequential control flow that requires visualization) Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@drtechie i have raised PR for fix: ignore applied migration checksums via config |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/main/resources/application-local.properties (1)
1-19: Consider documenting that credentials are example values.The hardcoded credentials (
user/password) should be documented as placeholder values for local development. Consider adding a comment indicating developers should customize these or use environment variable overrides.💡 Suggested documentation addition
Add a comment at the top of the file:
+# Local development configuration +# Replace user/password with your local database credentials or use environment variables + spring.datasource.dbiemr.url=jdbc:mysql://localhost:3306/dbiemr spring.datasource.dbiemr.username=user spring.datasource.dbiemr.password=password
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
pom.xmlsrc/main/java/com/db/piramalswasthya/config/FlywayConfig.javasrc/main/resources/application-local.propertiessrc/main/resources/application.properties
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/com/db/piramalswasthya/config/FlywayConfig.java (2)
src/main/java/com/db/piramalswasthya/config/DatasourceConfig.java (1)
Configuration(10-37)src/main/java/com/db/piramalswasthya/config/JdbcTemplateConfig.java (1)
Configuration(10-32)
🔇 Additional comments (4)
src/main/java/com/db/piramalswasthya/config/FlywayConfig.java (2)
15-16: LGTM: Property binding with sensible default.The @value annotation correctly binds to the new property with a safe default of
false(strict validation).
31-49: Excellent refactoring to eliminate duplication.The centralized
createFlywayhelper eliminates repetitive configuration code across all four Flyway beans. The delegation is clean and maintainable.src/main/resources/application.properties (1)
52-52: LGTM: Safe production default.Setting the default to
falseensures strict checksum validation in production environments, which is the correct security posture.src/main/resources/application-local.properties (1)
21-21: Appropriate setting for local development.Setting
ignore-applied-migration-checksum=truefor local development makes sense, as it allows developers to iterate on migrations without checksum validation failures.
| <dependency> | ||
| <groupId>org.projectlombok</groupId> | ||
| <artifactId>lombok</artifactId> | ||
| <version>1.18.36</version> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check latest Lombok version from Maven Central
echo "=== Latest Lombok Version ==="
curl -s 'https://search.maven.org/solrsearch/select?q=g:org.projectlombok+AND+a:lombok&rows=1&wt=json' | jq -r '.response.docs[0].latestVersion'
# Check for security advisories via GitHub
echo "=== Security Advisories ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: MAVEN, package: "org.projectlombok:lombok") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}' 2>&1 || echo "GitHub GraphQL query failed or no vulnerabilities found"Repository: PSMRI/AMRIT-DB
Length of output: 173
Update Lombok to version 1.18.38.
Version 1.18.36 is two minor versions behind the latest available version (1.18.38). No security vulnerabilities were found for the current version, but upgrading to 1.18.38 is recommended to maintain currency with the latest stable release.
🤖 Prompt for AI Agents
In pom.xml around line 55, the Lombok dependency version is pinned to 1.18.36;
update the <version> element to 1.18.38 to bring the dependency to the latest
stable release, then rebuild (mvn clean verify or mvn -U) to refresh the
dependency cache and ensure the project compiles with the new Lombok version.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
We manage environments with property files in environments folder.
This file should not be committed.
|
Thanks for the review @drtechie! Local Properties: Got it. I'll remove application-local.properties from the PR. I'll move the necessary local configs to my own local environment and ensure they stay out of the repo. Flyway Pattern: I also saw the bot's catch regarding the *:applied syntax. I'm looking into the correct pattern for the Community version now. I'll push an update shortly with these fixes! |
Updated ignoreMigrationPatterns to fix invalid pattern syntax for Flyway configuration.
|
|
Thanks for the review @drtechie. I've removed the application-local.properties file as requested. I also updated the Flyway pattern in FlywayConfig.java to use a valid status (*:Ignored) to fix the issue flagged by CodeRabbit. Let me know if everything looks good now! |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @src/main/java/com/db/piramalswasthya/config/FlywayConfig.java:
- Around line 22-35: The createFlyway method uses Flyway.
ignoreMigrationPatterns which is a Teams-only API and also does not suppress
checksum validation; remove the ignoreMigrationPatterns("*:Ignored") call in
createFlyway and instead disable validation for migrations in the Community
edition by calling configuration.validateOnMigrate(false) or perform
Flyway.repair() at startup where appropriate; update the conditional that checks
ignoreAppliedMigrationChecksum to set validateOnMigrate(false) (or trigger a
repair flow) so the app can start when local checksums differ without relying on
Teams-only methods.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/com/db/piramalswasthya/config/FlywayConfig.java
🧰 Additional context used
🧬 Code graph analysis (1)
src/main/java/com/db/piramalswasthya/config/FlywayConfig.java (2)
src/main/java/com/db/piramalswasthya/config/DatasourceConfig.java (1)
Configuration(10-37)src/main/java/com/db/piramalswasthya/config/JdbcTemplateConfig.java (1)
Configuration(10-32)
🔇 Additional comments (3)
src/main/java/com/db/piramalswasthya/config/FlywayConfig.java (3)
6-6: LGTM!The new imports are appropriate for the added functionality.
Also applies to: 8-8
15-16: LGTM!The configuration field with a safe default of
falseensures strict validation in production environments unless explicitly overridden.
37-55: Excellent refactoring!The consolidation of Flyway bean configuration into the centralized
createFlywayhelper eliminates code duplication and ensures consistent configuration across all four database sources.
| private Flyway createFlyway(DataSource dataSource, String location) { | ||
| FluentConfiguration configuration = Flyway.configure() | ||
| .dataSource(dataSource) | ||
| .locations(location) | ||
| .baselineOnMigrate(true); | ||
|
|
||
| if (ignoreAppliedMigrationChecksum) { | ||
| // Updated from "*:applied" to "*:Ignored" to fix invalid pattern syntax | ||
| // This allows the app to start even if checksums for applied migrations have changed locally | ||
| configuration.ignoreMigrationPatterns("*:Ignored"); | ||
| } | ||
|
|
||
| return configuration.load(); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and examine pom.xml for Flyway version
find . -name "pom.xml" -type f | head -5Repository: PSMRI/AMRIT-DB
Length of output: 67
🏁 Script executed:
# Extract Flyway dependency version
rg -A 3 'artifactId.*flyway' pom.xml | head -20Repository: PSMRI/AMRIT-DB
Length of output: 291
🏁 Script executed:
# Check the full FlywayConfig.java file to understand context
cat -n src/main/java/com/db/piramalswasthya/config/FlywayConfig.javaRepository: PSMRI/AMRIT-DB
Length of output: 2553
🏁 Script executed:
# Search for usage of ignoreAppliedMigrationChecksum flag
rg -n 'ignoreAppliedMigrationChecksum' --type javaRepository: PSMRI/AMRIT-DB
Length of output: 285
🏁 Script executed:
# Check if there's any documentation or comments about why this flag exists
rg -B 5 -A 5 'ignoreAppliedMigrationChecksum' src/Repository: PSMRI/AMRIT-DB
Length of output: 2244
🏁 Script executed:
# Extract complete Flyway dependency section with version
cat pom.xml | grep -A 5 "flyway-core" | head -10Repository: PSMRI/AMRIT-DB
Length of output: 244
🏁 Script executed:
# Check if there's a properties section defining flyway version
rg -A 2 'flyway.*version|<version>' pom.xml | head -30Repository: PSMRI/AMRIT-DB
Length of output: 573
🌐 Web query:
Flyway ignoreMigrationPatterns "*:Ignored" status Teams-only feature documentation
💡 Result:
Short answer
- ignoreMigrationPatterns accepts patterns of the form <migration_type>:<migration_state> (wildcard * allowed). Setting it to "*:ignored" tells Flyway to ignore migrations whose validation state is "Ignored" during validate (and is accepted by repair). [1][2]
Notes & pointers
- This is a Flyway Teams-only configuration (not Community). Use the config key flyway.ignoreMigrationPatterns or CLI/command flag -ignoreMigrationPatterns. [3][4]
- The parameter was introduced in Teams 7.8.1 and is documented in the Redgate Flyway docs and tutorials. [2][3]
Sources
[1] Redgate Flyway — Customize validation rules with ignoreMigrationPatterns (documentation).
[2] Redgate Flyway — Validate / error-code guidance referencing "*:ignored" as the way to ignore resolved-but-not-applied migrations.
[3] Redgate Flyway — Configuration reference mentioning flyway.ignoreMigrationPatterns and that it is Flyway Teams only.
[4] Redgate article / Hub guidance showing usage and examples for -ignoreMigrationPatterns.
🌐 Web query:
Flyway checksum mismatch ignored pattern validation behavior
💡 Result:
Short answer: ignoreMigrationPatterns controls which migrations the validate step ignores based on migration type:status (e.g., versioned:pending, repeatable:missing, *:ignored). It does NOT suppress checksum-mismatch validation — a CHECKSUM_MISMATCH still causes validate to fail. To resolve checksum mismatches you must either revert the script, run repair to update the schema history, or otherwise reconcile the change. [1][2][3]
Sources
- ignoreMigrationPatterns docs / tutorial (patterns are type:status). [1]
- Flyway error-code docs describing CHECKSUM_MISMATCH and recommended actions (revert or repair). [2]
- GitHub issues / discussion showing ignoreMigrationPatterns covers missing/pending/failed/ignored cases but does not eliminate checksum-mismatch behavior; users are directed to repair or revert. [3]
Flyway Teams-only feature unavailable in Community edition; semantic mismatch on checksum handling.
The project uses flyway-core (Community edition), but ignoreMigrationPatterns is a Flyway Teams-only feature. This call will fail at runtime with a method not found error.
Additionally, ignoreMigrationPatterns("*:Ignored") does not ignore checksum mismatches for applied migrations. The "Ignored" status refers only to migrations explicitly marked as ignored in the schema history table. When Flyway detects a checksum mismatch on an already-applied migration, it throws a validation error regardless of ignore patterns. The intent expressed in the comment—"allows the app to start even if checksums for applied migrations have changed locally"—is not achieved by this configuration.
To allow the application to start despite checksum changes in Community edition, use validateOnMigrate(false) instead, or run Flyway.repair() to fix checksums in the schema history table.
Recommended fix for Community edition
private Flyway createFlyway(DataSource dataSource, String location) {
FluentConfiguration configuration = Flyway.configure()
.dataSource(dataSource)
.locations(location)
.baselineOnMigrate(true);
if (ignoreAppliedMigrationChecksum) {
- // Updated from "*:applied" to "*:Ignored" to fix invalid pattern syntax
- // This allows the app to start even if checksums for applied migrations have changed locally
- configuration.ignoreMigrationPatterns("*:Ignored");
+ // Skip validation to allow app to start even if checksums
+ // for applied migrations have changed locally
+ configuration.validateOnMigrate(false);
}
return configuration.load();
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private Flyway createFlyway(DataSource dataSource, String location) { | |
| FluentConfiguration configuration = Flyway.configure() | |
| .dataSource(dataSource) | |
| .locations(location) | |
| .baselineOnMigrate(true); | |
| if (ignoreAppliedMigrationChecksum) { | |
| // Updated from "*:applied" to "*:Ignored" to fix invalid pattern syntax | |
| // This allows the app to start even if checksums for applied migrations have changed locally | |
| configuration.ignoreMigrationPatterns("*:Ignored"); | |
| } | |
| return configuration.load(); | |
| } | |
| private Flyway createFlyway(DataSource dataSource, String location) { | |
| FluentConfiguration configuration = Flyway.configure() | |
| .dataSource(dataSource) | |
| .locations(location) | |
| .baselineOnMigrate(true); | |
| if (ignoreAppliedMigrationChecksum) { | |
| // Skip validation to allow app to start even if checksums | |
| // for applied migrations have changed locally | |
| configuration.validateOnMigrate(false); | |
| } | |
| return configuration.load(); | |
| } |
🤖 Prompt for AI Agents
In @src/main/java/com/db/piramalswasthya/config/FlywayConfig.java around lines
22 - 35, The createFlyway method uses Flyway. ignoreMigrationPatterns which is a
Teams-only API and also does not suppress checksum validation; remove the
ignoreMigrationPatterns("*:Ignored") call in createFlyway and instead disable
validation for migrations in the Community edition by calling
configuration.validateOnMigrate(false) or perform Flyway.repair() at startup
where appropriate; update the conditional that checks
ignoreAppliedMigrationChecksum to set validateOnMigrate(false) (or trigger a
repair flow) so the app can start when local checksums differ without relying on
Teams-only methods.
|
@saurabh24thakur can you also explain how you have tested this? Thanks. |
|
Please check the open comments. Also, I can see the local properties file still in changed files. |
|
@saurabh24thakur any updates? |
2 participants
📋 Description
JIRA ID: N/A
This PR addresses the issue where the application fails to start if the checksum of an already applied Flyway migration file changes. This is a common scenario during development or when minor non-functional changes (like comments) are added to existing migrations.
Changes:
amrit.flyway.ignore-applied-migration-checksum.flyway.ignoreMigrationPatterns("*:applied")when this property is set totrue.falsein application.properties (safe for production).true) in application-local.properties for a smoother local development experience.lombokversion in pom.xml to1.18.36to support building with newer JDK versions (e.g., JDK 24).✅ Type of Change
ℹ️ Additional Information
Verification:
ignoreMigrationPatternswhen the property is active.Configuration:
amrit.flyway.ignore-applied-migration-checksum=false(Strict validation)amrit.flyway.ignore-applied-migration-checksum=true(Ignores checksums for applied migrations)Summary by CodeRabbit
Chores
Refactor
✏️ Tip: You can customize this high-level summary in your review settings.