When I started learning Spring, I noticed something about many of the tutorials I found.
They often showed how to use a feature, but not always why it worked or when you should choose one approach over another.
I learn best by building things and documenting what I discover, so I started a project called spring-by-example.
The idea is simple: instead of building one large application, Iโm creating a collection of small, focused examples where each example explores a specific Spring concept with clear explanations, tests, and documentation.
Iโm happy to say that Iโve now completed Module 02 - Spring Data. ๐
This module took me from the fundamentals of Spring Data repositories to more advanced ways of querying, mapping, and testing data.
The module covers:
- Spring Data Repositories
CrudRepository- Query Methods
@Query- Entity Mapping
- Entity Relationships
- Transactions
- Pagination
- Specifications
- Projections
- Auditing
- Custom Repositories
- Database Testing
One thing I really enjoyed about this module was seeing how much Spring Data can handle while still allowing you to take control when you need to.
I started with repository abstractions and CrudRepository, then explored how Spring Data can derive queries directly from method names.
For example:
List<Person> findByAgeGreaterThan(int age);
There's no SQL or JPQL in the method itself, but Spring Data can interpret the method name and create the appropriate query.
From there, I explored @Query for cases where defining the query explicitly makes more sense.
Then came entity mapping and relationships.
Working with @OneToOne, @OneToMany, @ManyToOne, and @ManyToMany helped me understand how object relationships are represented in the persistence layer rather than simply treating entities as isolated classes.
Transactions were another important part of the module.
I explored how multiple database changes can be grouped into a single transactional operation and, more importantly, how a failure partway through an operation can cause those changes to be rolled back.
Pagination and Specifications then showed two different ways of building more flexible queries.
With Specifications, I could compose criteria dynamically:
Specification<Person> specification =
PersonSpecifications.nameContains("Jan")
.and(PersonSpecifications.ageGreaterThan(30));
Projections introduced another useful idea: sometimes you don't need the entire entity.
Instead, you can retrieve only the data required by a particular use case.
I also explored auditing with annotations such as:
@CreatedDate
@LastModifiedDate
@CreatedBy
@LastModifiedBy
This helped me understand how Spring Data can automatically track information about when an entity was created or modified and who performed the operation.
Custom repositories were another interesting step.
Instead of relying entirely on derived queries and @Query, I explored repository fragments and how a custom implementation can be composed with a Spring Data repository.
Finally, I finished the module with database testing.
Using @DataJpaTest, H2, and @Sql, I explored how repository behavior can be tested against an actual database rather than relying only on mocks.
That distinction was particularly useful because a mocked repository cannot tell you whether a JPQL query, entity mapping, or derived query actually works against the database.
The goal isnโt just to learn how to write:
PersonRepository
The bigger goal is to understand what Spring Data is doing for me, where its conventions help, and when I should take more control.
The project is open source, and Iโm continuing to build it as I learn:
๐ GitHub: https://gith.ub/dsAQrAU5
๐ GitLab: https://gitl.ab/gfDEyGH3
Thereโs still a long way to go, but completing Module 02 - Spring Data feels like another important milestone. ๐
Next up: Module 03 - Reactive Spring - moving from traditional blocking application development into reactive programming with Spring.
One focused example at a time. ๐
If youโve worked with Spring Data before, which feature do you find most useful in your day-to-day development - derived queries, Specifications, projections, transactions, or something else?
Top comments (0)