¿Qué es el problema N+1 en Hibernate y cómo se puede…

El problema N+1 en Hibernate ocurre al consultar datos, cuando se realiza una consulta para obtener los objetos padre y luego, para cada objeto hijo (o colección de objetos hijos), se realiza una consulta separada. Esto conduce a N+1 consultas a la base de datos, donde N es la cantidad de objetos padre, en lugar de una consulta óptima o unas pocas consultas con uniones.

Ejemplo de escenario con el problema N+1:

Supongamos que hay clases Author y Book, donde un autor puede tener muchas libros.

// Entidad Author
@Entity
public class Author {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY) // Fetch LAZY por defecto para colecciones
    private List<Book> books;

    // getters y setters
}

// Entidad Book
@Entity
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;

    @ManyToOne
    private Author author;

    // getters y setters
}

Si queremos mostrar todos los autores y los títulos de sus libros:

Session session = sessionFactory.openSession();
List<Author> authors = session.createQuery("FROM Author", Author.class).list(); // 1 consulta a Author

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) { // N consultas a Book (una por cada autor)
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

En este ejemplo:

Se realiza una consulta para obtener todos los Author.
Luego, en un ciclo, para cada Author, se realiza una consulta separada para cargar la colección books. Si hay 100 autores, se realizarán 100 consultas adicionales a la tabla Book. En total, 1 (para autores) + 100 (para libros) = 101 consultas.

Soluciones al problema N+1:

Usar JOIN FETCH en JPQL/HQL: Carga explícitamente las entidades relacionadas en una sola consulta.

Session session = sessionFactory.openSession();
List<Author> authors = session.createQuery("SELECT DISTINCT a FROM Author a JOIN FETCH a.books", Author.class).list(); // Carga Author y sus Books en una sola consulta

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) {
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

La cláusula DISTINCT se usa para evitar duplicados en el resultado, que puede ocurrir con joins uno-a-muchos.

Cambiar el tipo de carga a EAGER: Modificar fetch = FetchType.LAZY (por defecto en colecciones) a fetch = FetchType.EAGER.
```
@Entity
public class Author {
    // ... otros campos
    @OneToMany(mappedBy = "author", fetch = FetchType.EAGER) // carga EAGER
    private List<Book> books;
    // ... getters y setters
}
```
No recomendado para colecciones o entidades con muchas relaciones, ya que puede cargar datos innecesarios y afectar el rendimiento (efecto "producto cartesiano"). Es adecuado para relaciones ManyToOne/OneToOne, donde se espera que el objeto relacionado siempre sea necesario.

Usar FetchMode en Criteria API: Permite especificar cómo se cargan las entidades relacionadas.

Session session = sessionFactory.openSession();
Criteria criteria = session.createCriteria(Author.class)
    .setFetchMode("books", FetchMode.JOIN); // Usa LEFT OUTER JOIN para cargar books

List<Author> authors = criteria.list();

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) {
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

Usar la anotación BatchSize: Indica a Hibernate que cargue las entidades relacionadas (o colecciones) en grupos de un tamaño determinado, reduciendo el número de consultas, aunque no las reduce a una sola.
```
@Entity
@BatchSize(size = 10) // Hibernate cargará los Author en lotes de 10
public class Author {
    // ... otros campos
    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY)
    @BatchSize(size = 10) // Hibernate cargará los books en lotes de 10 por Author
    private List<Book> books;
    // ... getters y setters
}
```
Al recorrer la colección books del primer autor, Hibernate cargará books para los siguientes 9 autores si están en la misma sesión. Esto reduce significativamente el número de consultas comparado con N+1.

Usar Entity Graphs: Permiten definir explícitamente qué objetos relacionados o colecciones deben cargarse en una consulta.

@NamedEntityGraph(name = "author-with-books",
    attributeNodes = @NamedAttributeNode("books")
)
@Entity
public class Author {
    // ... campos y relaciones
}

Session session = sessionFactory.openSession();
jakarta.persistence.EntityGraph<Author> entityGraph = session.createEntityGraph(Author.class);
entityGraph.addAttributeNodes("books");

List<Author> authors = session.createQuery("SELECT a FROM Author a", Author.class)
    .setHint("jakarta.persistence.fetchgraph", entityGraph) // o fetchgraph según comportamiento deseado
    .getResultList();

for (Author author : authors) {
    System.out.println("Author: " + author.getName());
    for (Book book : author.getBooks()) {
        System.out.println("- Book: " + book.getTitle());
    }
}
session.close();

La elección de la solución específica depende del contexto, la relación uno-a-uno/uno-a-muchos/muchos-a-muchos, volumen de datos y flexibilidad requerida. JOIN FETCH y los Entity Graphs suelen ser preferidos para cargar todos los datos relacionados en una sola consulta, mientras que BatchSize es eficiente cuando se trabaja con muchas entidades y JOIN FETCH genera resultados demasiado grandes. La carga EAGER debe usarse con precaución.

¿Qué es el problema N+1 en Hibernate y cómo se puede resolver?