Add the Database to Our Application

In the previous chapter, we covered what JPA and Hibernate are. In this chapter, we will integrate a database into our application and try performing CRUD operations (Create, Read, Update, Delete).

Example of Working With a Database:

//VIDEO

Model Customization

The first thing we need to do is annotate the model so that Hibernate can work with it and understand which table it belongs to.

Book


              123456789
            
@Getter
@Setter
@Entity(name = "book")
public class Book {
    private String id;
    private String name;
    private String author;
    private String price;
}

We specify the annotation @Entity(name = "books") above the class, and in the attributes, we pass the name of the table that this model will be associated with. In our case, this table is created through migrations, so we do not need to create it manually.

We also need our entity to automatically generate an ID to assign it a unique value in the database. To achieve this, we can use the @Id annotation on the field that represents our ID, along with the @GeneratedValue annotation.

The annotations @Id and @GeneratedValue(strategy = GenerationType.UUID) specify that the id field is a primary key that is automatically generated in UUID format.

Note
The @GeneratedValue annotation has multiple options for ID generation, but since we are using a string for the id, it is convenient to generate it with GenerationType.UUID.

This ensures unique string identifiers for each record in the table, which is beneficial for distributed systems and guarantees global uniqueness of the identifiers. UUID are stored as strings.

Adding the Repository

Currently, our repository simulates a database by storing all entities in a List. But what if I told you that using a real database is actually much easier!

To interact with a real database, we can use the JpaRepository interface, which provides a wide range of built-in methods for working with data.

BookRepository


              1234
            
@Repository
public interface BookRepository extends JpaRepository<Book, String> {
      // JpaRepository already provides methods for CRUD operations
}

In JpaRepository<Book, String>, we pass two parameters: Book, which represents the entity type that the repository will work with, and String, which is the data type of the primary key (ID) for the Book entity.

And that’s all we need! Now we have a fully functional repository!

JpaRepository Main Methods

Note
We don't need to write implementations for these methods at all—their implementations will be automatically generated based on the entities, and that is incredibly awesome!

Creating Custom SQL Queries

Spring Data JPA can automatically generate queries if the method is named according to a pattern that aligns with the data structure. This is done using specific keywords that indicate how the query should be constructed.

//VIDEO

This method automatically generates an SQL query that searches for all books by the specified author. The generated query will look like this:

How it Works

The method name findBookByAuthor(String author) is constructed as follows: it starts with the prefix findBook, indicating that the method performs a search. Next comes ByAuthor, which represents the field in the Book entity that will be used for the search.

When this method is called, Spring Data JPA automatically generates a query that searches for records where the author field matches the provided parameter.

Generating SQL Queries with the @Query

The @Query annotation in Spring Data JPA allows you to use both JPQL and native SQL, providing flexibility in choosing the appropriate approach.

JPQL

JPQL (Java Persistence Query Language) works with objects and their properties.

This query searches for all Book objects where the author field matches the provided value. JPQL is more abstract and reflects the data model structure.

Native SQL

Native SQL directly interacts with database tables.

In this case, the query operates on the book table, allowing the use of specific SQL functions and optimizations.

Choosing an Approach

If you need a simple query that aligns with the data model, use JPQL. If a complex query or database-specific functions are required, choose native SQL.

Thus, @Query provides the flexibility to easily switch between the two approaches based on your needs.

¿Todo estuvo claro?

Sección 4. Capítulo 5