Question
Transactional Rollback versus Snapshot Restore for DDL Safety in Cucumber-JVM
Ash Byte
0 reputation · 15 Aug 2021, 08:44 UTC
145.9K views
Loading…
0 reputation · 15 Aug 2021, 08:44 UTC
The goal is to maintain database schema consistency after a Cucumber scenario that includes data-definition-language statements, given that most relational databases issue an implicit commit when DDL executes. Because Cucumber-JVM's @Transactional annotation only rolls back data-manipulation operations, schema changes such as ADD COLUMN persist beyond the scenario boundary, creating a mismatch between expected and actual database state.
A concrete constraint arises from the documented behavior that transactional rollback mechanisms in common test harnesses do not revert DDL, while alternative schema snapshot/restore approaches introduce runtime overhead and may complicate parallel execution if isolation per thread is not guaranteed. This trade-off forces a design decision between relying on manual DDL cleanup and adopting a restore mechanism that may impact test suite throughput.
What factors determine whether a specific database vendor treats DDL as transactional? How does a schema snapshot/restore workflow interact with Cucumber's scenario-level hooks when tests run in parallel? Which approach provides the lowest persistent schema drift with acceptable impact on test execution speed?
35775 reputation · 15 Aug 2021, 09:22 UTC
Transactional rollback only reverts DDL on databases that support transactional DDL (primarily PostgreSQL). Snapshot/restore via Cucumber hooks guarantees zero schema drift but adds latency and requires per-thread isolation for parallel runs. For lowest persistent drift with acceptable speed: use transactional rollback on PostgreSQL; otherwise adopt snapshot/restore with container-per-thread or unique-schema isolation.
cucumberCREATE DATABASE cannot roll back).VACUUM, CREATE INDEX CONCURRENTLY, and some ALTER TABLE variants run outside transactions.@Transactional relies on Spring or Jakarta EE; ensure the transaction boundary encloses the DDL statement.Typical workflow:
@Before: spin up a clean schema (via Flyway/Liquibase migration or SQL script) or restore a volume snapshot.@After: tear down schema or discard container.Parallel execution demands isolation:
| Approach | Persistent Drift | Typical Overhead | Parallel Friendly |
|---|---|---|---|
| Transactional rollback (PostgreSQL) | Zero (if DDL transactional) | Low (ms) | Yes |
| Transactional rollback (MySQL/Oracle) | High (DDL commits implicitly) | Low | Yes |
| Snapshot/restore (container) | Zero | High (seconds) | With per-thread containers |
| Snapshot/restore (schema reload) | Zero | Medium (hundreds of ms) | With unique schemas |
| Manual DDL cleanup | Unreliable (depends on test outcome) | Low | Risky |
@Transactional that executes CREATE TABLE test_ddl (id INT); after failure, check if table exists.@Transactional vs container restart using a simple JUnit 5 test.mvn test -DforkCount=4) and inspect for schema collisions.Which database vendor and version are you targeting? This single fact determines whether transactional rollback is viable and shapes the snapshot/restore strategy.
ALTER TABLE ... ADD COLUMN vs CREATE INDEX) may vary; mark for review per vendor documentation.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.