Explicit Gradle try/catch rollback versus migration-tool recovery for schema changes

The Short Answer

No, the transactional flag is not sufficient to guarantee a full rollback of schema changes. Its effectiveness is limited by the database engine's support for Transactional DDL. Furthermore, Gradle's up-to-date checks can mask partial failures because they track task inputs and outputs, not the internal state of the database. You should trust a dedicated migration tool's native recovery mechanisms rather than implementing compensatory logic in Gradle build scripts.

Transactional Flags and DDL Limitations

The transactional=true flag typically wraps JDBC statements in a transaction. However, many relational databases (such as MySQL and Oracle) trigger an implicit commit whenever a Data Definition Language (DDL) statement (e.g., ALTER TABLE, CREATE INDEX) is executed. In these environments, once a DDL statement succeeds, it cannot be rolled back, even if a subsequent statement in the same script fails.

Verification Step

To verify your database's behavior, run a script with two DDL statements where the second contains a syntax error. If the first change persists in the schema after the build fails, your database does not support transactional DDL, and the Gradle flag is ineffective for rollbacks.

Gradle's Up-to-Date Checks and Visibility

Gradle determines if a task is UP-TO-DATE by comparing fingerprints of inputs and outputs. Because the database is an external state not managed by Gradle's filesystem-based tracking, a partial migration may occur without updating the task's designated output markers. This creates a discrepancy where Gradle believes the task is complete or skipped, while the database remains in an inconsistent, partially migrated state.

Recommended Recovery Strategy

Avoid implementing try/catch blocks in Gradle to handle rollbacks; build scripts lack the granular state tracking required to undo specific schema changes safely. Instead, utilize a dedicated migration tool (e.g., Flyway or Liquibase) for the following reasons:

• Metadata Tracking: These tools maintain a version table within the database to track exactly which migrations have been applied.
• Idempotency: They encourage the use of versioned scripts that can be validated before execution.
• Failure Detection: They can detect "failed" migration checksums on startup, forcing a manual or automated repair of the schema version table.

Safe Execution Command

If you suspect a partial migration has occurred and Gradle is skipping the task, force a re-execution to trigger the migration tool's internal validation:

./gradlew migrateTask --rerun-tasks

Missing Diagnostic: To provide a more specific recommendation, please specify the database engine and version (e.g., PostgreSQL 15 vs. MySQL 8.0), as this determines whether transactional DDL is natively supported.