Flamingock: Changes & Target Systems

This section documents schema/database evolution using version-controlled migration tools — Liquibase (relational/SQL), Mongock (MongoDB, Java-native) and Flamingock (Mongock’s successor, generalized to any external system) — as described by each tool’s own official documentation: liquibase.org and docs.liquibase.com for Liquibase, docs.mongock.io for Mongock, and docs.flamingock.io for Flamingock — which are the references these pages are written and verified against.

This content was generated with the assistance of AI and should be verified against those official docs before being relied on in production.

Mongock is now maintained under the Flamingock GitHub organization (github.com/flamingock/mongock), and Flamingock is positioned as its successor — see Coming from Mongock. Readers starting a new project should default to Flamingock unless they have a specific reason to stay on Mongock.

This section’s bibliography lists the reference material consulted while preparing these pages.

Anatomy of a Change

A Flamingock @Change is identified the same way as a Mongock @ChangeUnit (Mongock: ChangeUnits) — a unique id, an order, and an author — plus one addition: a declared target system, naming which external system the change applies to. Its two methods:

  • @Apply — mandatory, the forward operation.

  • @Rollback — the inverse. For a transactional target system (a relational database, or MongoDB on a replica set), Flamingock can lean on the target’s own transaction to undo a failed @Apply automatically, so @Rollback is optional there in the same spirit as Mongock’s "highly recommended." For a non-transactional target system, there is no such safety net — see below.

Why @Rollback Is Required for Non-Transactional Systems

An object store, a message queue, or a call to a third-party REST API has no transaction to roll back: once a message is published or a request is sent, the side effect has already happened outside Flamingock’s control. For target systems like these, Flamingock treats @Rollback as required, because it is the only mechanism that can undo a partially-applied change at all:

@Change(id = "publish-tenant-provisioned-event", order = "010", author = "alberto",
         targetSystem = "tenant-events-queue")
public class PublishTenantProvisionedEventChange {

    @Apply
    public void apply(MessageQueueClient queue) {
        queue.publish("tenant.provisioned", new TenantProvisionedEvent(tenantId()));
    }

    @Rollback
    public void rollback(MessageQueueClient queue) {
        queue.publish("tenant.provisioning-cancelled", new TenantProvisioningCancelledEvent(tenantId()));
    }
}

Here, @Rollback doesn’t literally "undo" the publish (the original message may already be consumed) — it publishes a compensating event instead, which is the general shape a rollback takes against a non-transactional system: not an inverse operation, but a compensating one. This is exactly why Flamingock’s safety-by-default principle (Flamingock: Getting Started) matters more here than for a transactional database change — without a rollback path, a failure partway through a pipeline touching a queue leaves no safe way back, so Flamingock stops rather than guessing.

Target Systems

Flamingock’s target-system abstraction is what lets one pipeline coordinate changes across systems that would otherwise each need their own tool:

Target system Notes

SQL (relational)

Transactional; similar guarantees to Liquibase’s target databases.

MongoDB (sync / Spring Data)

Transactional on a replica set/sharded cluster, same as Mongock (Mongock: Transactions & Locking).

DynamoDB

Non-relational, AWS-managed; transactional guarantees are narrower than a relational database’s.

Couchbase

Document database; see the Couchbase Reference for the target system itself.

Non-transactional systems (message brokers, external APIs, cloud services)

No native transaction to lean on — @Rollback is required, as above.

See Target Systems — Introduction for the full, up-to-date list and configuration per target.

The Audit Store

Every @Apply/@Rollback execution, across every target system in a pipeline, is recorded in Flamingock’s audit store — a single, configurable place for the full execution history, decoupled from any one target system (unlike Liquibase’s DATABASECHANGELOG, which lives inside the database it’s tracking). This is what makes "complete auditability" (Flamingock: Getting Started) possible even when a pipeline’s changes never touch a traditional database at all.