Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.
Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.
In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:
1. Introduction
In this era of continuous integration and automated refactoring to database development, we need techniques of evolutionary database design. Tools like Liquibase and Flyway follow these techniques and provide an iterative development approach. In this article, we will study the differences and similarities between Liquibase and Flyway.
Note that no tool is perfect for all the use cases. Each tool is strong in its own place.
2. Similarities Between Liquibase and Flyway
Since Liquibase and Flyway implement the design principles of the evolutionary database they offer a lot of similar functionality. Both tools:
- Are open-source to an extent and help manage, track and deploy database schema changes.
- Use a versioned migration approach to a database schema change.
- Are based on Java and provides extensive support for Java frameworks like Spring Boot and Vert.x.
- Support integration with build tools like Maven and Gradle.
- Can run independently from the command line through provided scripts.
- Support a wide variety of databases.
Now we will discuss the differences between the offerings of these tools.
3. Differences Between Liquibase and Flyway
3.1. Defining a Change
Flyway uses SQL for defining a change. On the other hand, Liquibase provides flexibility to specify a change in different formats including SQL such as XML, YAML, and JSON. With Liquibase we can work with database-agnostic languages and easily apply schema changes to different database types.
Flyway is built around a linear database versioning system that increments on each versioned change. This sometimes can create conflicts with parallel development. The filename of a Flyway script defines the type of migration. For example, a migration should have a convention of prefixes as V (for versioned), U (for undo), and R (for repeatable). It will be followed by a version number and a separator __(two underscores) followed by a description and a suffix .sql such as V01__Add_New_Column.sql.
Liquibase migration doesn’t need to follow any of the file name conventions. In Liquibase, changes are managed by one ledger known as a master changelog which will be defined as including all the migrations.
3.2. Storing a Change
Both the tools store the deployed change in a table. Flyway migrations are stored in the database schema with a default table named flyway_schema_history. Similarly, Liquibase stores its deployed migrations in a table named databasechangelog. Both the tools support overriding default configuration to change the table name.
3.3. Execution Order of a Change
Managing the order of a change is comparatively difficult in Flyway. With Flyway, the order depends on the version number and migration type in the filename. Contrarily, Liquibase uses a separate file named master_changelog in which the changes are deployed in the order they are defined.
3.4. Rollback a Change
Now, let’s discuss one of the main aspects of database migration. Rollback is needed whenever a bad change has caused a catastrophic issue in the application. Liquibase provides a way to roll back everything or undo specific migrations (available only on paid versions).
Flyway also has a undo migration, which can be deployed with a file name that starts with U followed by the version that needs to be undone. Its paid version also offers even more complex undo functionality.
Both the tools offer a decent rollback functionality, but considering only the free version, Flyway offers a good-to-use solution.
3.5. Selective Deployment of a Change
There are use cases where we need to deploy a change to only one environment. Liquibase wins here when we’ve to selectively deploy a change. Flyway is also capable of doing it, but you would have to set up a different configuration file for each environment or database. With Liquibase we can easily add labels and contexts to ensure deployment in certain places.
3.6. Java-Based Migration
Both tools are strongly Java Oriented and provide Java-based migration. Flyway and Liquibase allow defining a migration within a Java file. This can be advantageous in some scenarios.
3.7. Snapshots & Comparing Databases
Liquibase allows users to take a snapshot of the current state of the database. We can use this state to compare it to another database. This would be very helpful in scenarios like failover and database replication. Flyway on the other hand doesn’t support any of the snapshot features.
3.8. Conditional Deployment
Liquibase offers an added feature called pre-conditions. Preconditions allow users to apply changes based on the current state of the database. A changeset will only execute if it passes these preconditions.
Flyway on the other hand doesn’t support this. But through procedures, we can apply conditions in most SQL-based databases.
4. Conclusion
In this article, we compared two of the most used database migration tools Liquibase and Flyway. There are always tradeoffs to make when choosing between tools. There are no strong drawbacks or advantages either of the tools have when compared to one another. You can pick either Liquibase or Flyway based on your application needs and check most of the boxes.
