Considering the size of UUID it is questionable if it is a right choice, but often it is not up to us to decide.

This article does not focus on "if UUID is the right format for a key", but how to use UUID as a primary key with PostgreSQL efficiently.

TIP

Projection is a subset of an aggregate loaded from a repository for read-only purposes.

Methods returning projections are typically defined on the repository level, making the repository interface aware of all possible types of projections used in the application.

package com.app.account.domain;

public interface AccountRepository extends Repository<Account, String> {
    AccountBasic findAccountBasicById(String id);
    AccountComplete findAccountCompleteById(String id);
}

public record AccountBasic(String id, 
                           String iban,
                           String bic) {}

public record AccountComplete(String id,
                       String iban,
                       String bic,
                       State state,
                       Type type,
                       LocalDateTime createdAt) {}

This approach has some drawbacks:

• if there is a projection that almost fits our use case, it is tempting to modify it and add needed field - at the same time defeating a bit the main purpose of projections - fetching only what's needed.
• naming projections becomes a challenge - how to name them? AccountBasic? AccountLight? AccountData? All these names are quite meaningless.
• repository becomes difficult to use as it contains a long list of method, and to find out which one should be used you need to visit every projection.
• because projections are shared between use cases, they become a coupling point, making future refactoring more difficult.
• projections must have the same visibility level as the repository, for example if repository is public, projections must be public too.

Instead of making the repository aware of all types projections used by all the use cases, we can use dynamic projections.

A good example is Jackson's ObjectMapper#readValue method with following signature:

public <T> T readValue(String content, Class<T> valueType) {
    ...
}

Passing class as a parameter looks repetitive. Since <T> defines the type, why do we need to pass Class<T>? Why it can't be simplified to:

public <T> T readValue(String content) {
    ...
}

And most importantly, how is Mockito able to find out the type of mock in such code?

Book book = mock();
Person person = mock();

INFO

Advice given in this article is especially relevant to applications with hundreds of Flyway migration files.

In Spring Boot & Flyway - clear database between integration tests I described how to ensure that each integration test starts with clean state - wipe out content from the database, and all database migrations applied from scratch. Such approach simplifies writing tests but comes with one significant drawback - running database migration takes time. The more migration files, the longer it takes. I still believe this is a solution worth considering for small services, but for large applications with hundreds or thousands of migrations, time needed to run migrations may become a biggest factor contributing to slow integration tests.

In this article I'll explore how reusable containers can significantly speed up integration tests during development phase and how to configure Flyway to use them efficiently.

I believe that in some specific use cases, following this approach can dramatically simplify your architecture and implementation. Let's see step by step how to do it.

Specifically, I am looking for a solution that meets following criteria:

• as little overhead as possible
  • containers are started only once for all tests
  • containers are started in parallel
• no requirement for test inheritance
• declarative usage

In this short tutorial you'll see how to clean a database between integration tests. The recipe assumes that you use: relational database (like MySQL or PostgreSQL), Spring Boot, Flyway - for database migrations, JUnit 5.

Even if you don't use exactly these technologies, overall idea is quite generic, so I am sure you can adjust it to your needs.

You will also learn the following:

• why it is important to clear the database in integration tests
• how to clear the database using JdbcTemplate, Spring Data repositories and Flyway
• how to create custom JUnit 5 extension
• how to create JUnit 5 meta-annotations

If you feel a little overwhelmed with the constant stream of news from the Spring team - I hear you. November was a very hot month for Spring developers. In addition to plenty of Spring project portfolio releases there were few interesting changes that you might have missed.

Below I collected the most important things (and added some notes) that I believe you - as a Spring developer - should know to stay up to date.

In rare cases, project build may require different configuration depending on operating system that runs the build.

In Maven, it can be done with Maven Profiles.

• how to configure profiles per operating system
• the trick to activate profile on Linux but not on Mac
• how to enforce presence of active profile with maven-enforcer-plugin
• how to run build on different operating systems with GitHub action