Estrat�gias de busca (fetch) com Hibernate

O Hibernate � um poderoso container que auxilia nas tarefas que envolvem o banco de dados, fazendo com que o desenvolvedor trabalhe diretamente com objetos e deixe que o Hibernate se encarregue de fazer a �traduç�o� de objetos para tabelas (relacional).

Este artigo aplica-se a um dos milhares de conceitos envolvidos neste poderoso container, a estrat�gia de busca, principalmente utilizando a linguagem HQL (Hibernate Query Language).

Quando uma pesquisa � feita no Hibernate, ele utiliza umas das estrat�gias de busca que ser�o mostradas abaixo, e o uso adequado destas pode trazer uma melhora significativa no desempenho da sua aplicaç�o.

Estrat�gias de Busca (Fetching Strategies)

S�o 4 as estrat�gias utilizadas para busca de dados com o Hibernate:

Join
Select
Subselect
Batch-size

Estrat�gia SELECT

Se voc� tem uma classe Venda e uma classe ItemVenda, onde a relaç�o de Venda para ItemVenda � um @OneToMany, provavelmente voc� ter� uma coleç�o de ItemVenda dentro de Venda. Utilizando esta estrat�gia, quando voc� carregar uma Venda os itens desta venda n�o ser�o carregados at� que voc� explicitamente os chame, ou seja, enquanto voc� n�o precisa destes itens eles n�o ser�o carregados.

Listagem 1: C�digo principal


//chama o select da venda
Venda venda = (Venda)session.get(Venda.class, 114); 
Set sets = venda.getAllItens();
 
//chama o select do ItemVenda
for ( Iterator iter = sets.iterator();iter.hasNext(); ) { 
      ItemVenda item = (ItemVenda) iter.next();
      System.out.println(item.getNome());
      System.out.println(item.getValor());

Veja na sa�da abaixo que o Hibernate s� constr�i o SQL do ItemVenda quando voc� o chama, ou seja, no laço �for�.

Listagem 2: Sa�da do Fetch SELECT


Hibernate: 
    select ...from venda
    where venda0_.VENDA_ID=?
 
Hibernate: 
    select ...from itemvenda
    where itemvenda0_.VENDA_ID=?

Estrat�gia JOIN

Ao contr�rio da SELECT, a JOIN desabilita o Lazy Loading, isto significa que ao carregar o objeto Venda, automaticamente todos seus itens s�o carregados, mesmo que voc� nunca precise destes.

Ainda seguindo o c�digo da Listagem 1, voc� poder� ver na Listagem 3 o que muda do FETCH SELECT para FETCH JOIN.

Listagem 3: Sa�da do Fetch JOIN


Hibernate: 
    select ...
    from
        venda venda0_ 
    left outer join
        itemvenda itemvenda1_ 
            on venda0_.VENDA_ID=itemvenda1_.VENDA_ID 
    where
        venda0_.VENDA_ID=?

Estrat�gia SUBSELECT

Para esta estrat�gia utilizaremos um outro c�digo principal para melhor ilustr�-lo. O que ocorre aqui � a criaç�o de uma �sub-query� para captura das collections. Veja o c�digo principal abaixo.

Listagem 4: C�digo Principal para Subselect


List<Venda> list = session.createQuery("from Venda").list();
 
for(Venda venda : list){
 
    Set sets = venda.getAllItens();
 
    for ( Iterator iter = sets.iterator();iter.hasNext(); ) { 
            ItemVenda item = (ItemVenda) iter.next();
            System.out.println(item.getNome());
            System.out.println(item.getValor());
    }
}

Aplicando a estrat�gia de SUBSELECT a sa�da ser�:

Listagem 5: Sa�da do SUBSELECT


Hibernate: 
    select ...
    from venda venda0_
 
Hibernate: 
    select ...
    from
        itemvenda itemvenda0_ 
    where
        itemvenda0_.VENDA_ID in (
            select
                venda0_.VENDA_ID 
            from
                venda venda0_
        )

Com o subselect ser�o criados 2 SELECTs, sendo o primeiro para retornar apenas as Vendas e o segundo para retornar os Itens desta venda.

Estrat�gia Batch Size

Vamos explicar essa estrat�gia com exemplos, mas antes de iniciarmos tenha em mente o seguinte conceito: �A Estrat�gia de Batch Size n�o define quantos registros s�o carregados dentro das collections. Ao inv�s disso, ela define quantas collections dever�o ser carregadas�.

Veja o exemplo de c�digo abaixo que utilizaremos.

Listagem 6: C�digo para Exemplo Batch Size


List<Venda> list = session.createQuery("from Venda").list();
 
for(Venda venda : list){
 	Set sets = venda.getAllItens();
 
    for ( Iterator iter = sets.iterator();iter.hasNext(); ) { 
            ItemVenda item = (ItemVenda) iter.next();
            System.out.println(item.getNome());
            System.out.println(item.getValor());
    }
}

Sem utilizar o Batch Size a sa�da do Hibernate para o c�digo acima, ser�:

Listagem 7: Sa�da sem Batch Size


Hibernate: 
    select ...
    from venda venda0_
 
Hibernate: 
    select ...
    from itemvenda itemvenda0_ 
    where itemvenda0_.VENDA_ID=?
 
Hibernate: 
    select ...
    from itemvenda itemvenda0_ 
    where itemvenda0_.VENDA_ID=?

Dependendo de quantas Vendas estiverem no banco, ele ficar� criando SELECTs e mais SELECTs. Para resolver isso usamos o Batch Size, que transformar� a sa�da acima na sa�da abaixo (utilizando um Batch Size de tamanho 10).

Listagem 8: Sa�da com Batch Size = 10


Hibernate: 
    select ...
    from venda venda0_
 
Hibernate: 
    select ...
    from itemvenda itemvenda0_ 
    where
        itemvenda0_.VENDA_ID in (
            ?, ?, ?, ?, ?, ?, ?, ?, ?, ?
        )

O que o Hibernate faz � juntar todos aqueles SELECTS em uma clausula �IN�, o que torna a consulta milh�es de vezes mais �gil.

Conclus�o

� fato que o entendimento de cada uma dessas estrat�gias pode fazer diferença na hora de colocar sua aplicaç�o em produç�o, isso porque a n�o utilizaç�o adequada do mesmo pode trazer diversos problemas: lentid�o, estouro de pilha (stack overflow) e principalmente a constante reclamaç�o do usu�rio.

Uma aplicaç�o n�o � composta apenas de c�digo e retornos, pelo contr�rio, este � apenas o baseline desta, h� necessidades constantes de an�lise, projetos, testes e muitos outros recursos que completam a mesma. Se voc� ainda trabalha com aplicaç�es pequenas com uma �nfima quantidade de dados, poder� n�o sentir diferença na aplicaç�o das estrat�gias de busca, mas � ideal e quase que obrigat�rio o seu aprendizado desde o inicio para ao trabalhar com grandes aplicaç�o n�o ter surpresas.