Quem utiliza Criteria já deve ter precisado utilizar funções aninhadas ( como sum(abs(propriedade)) ). Infelizmente a class Projections não dispoem deste recurso, e a classe que implementa as agregações ( AggregateProjection ) não foi projetada pensando nisso.

Baseado na class AggregateProjection implementei uma solução com um construtor que recebe um array de string com as funções a serem aninhadas na ordem do array

Leia o artigo completo »

Ontem meu amigo Filipe Sabella queria executar uma função para manipulação de data do Oracle utilizando Criteria. Algo do tipo funcao_do_oracle( columa ) = ?

O Hibernate não implementa esse tipo de funcionalidade, mas por ter seu desenvolvimento baseado em interfaces lhe possibilita extender / criar (quase) toda e qualquer funcionalidade que deseje. Depois de dar o caminho das pedras, dizendo que era "so" implementar Criterion e algumas alterações para deixarmos a mesma compativel com 1.4 chegamos a seguinte solução:

Pronto. Agora e so adicionar ao seu criterio:

Meu primeiro post neste blog gerou algumas duvidas que rendem ate hoje alguns emails sobre o porque de se popular apenas o necessário.

A maioria dos projetos onde utilizamos Hibernate, a camada de front end e de back end são Java.

Em um simples cenário onde temos uma combo a qual precisamos apenas do Id e do Nome de uma determinada classe que em seu total dispõem de muitos atributos, fazemos a pesquisa normalmente com o Hibernate que popula todos seus atributos mandamos pra camada de front end ( JSP por exemplo ) que esta preparada para utilizar apenas o Id e o Nome da class transformando apenas as informações necessários para a tela do usuário em um HTML, dispensando os dados que não serão utilizando. Tudo isso no lado do Servidor. A consulta por 2 ou 30 campos em sua maioria não faz "tanta" diferença para o banco e a transformação em dados desnecessário em HTML quando front end e back end estão no mesmo servidor ( não sendo aplicações realmente distribuídas ) também não faz "tanta" diferença.

Porem quando utilizamos flex no front end estamos trafegando uma imensidão ( exagerei? ) de dados desnecessariamente, forçando a maquina do usuário a tratar todos esses dados que em sua maioria não serão utilizados. Algumas vezes a coisa pode se tornar ainda pior quando precisamos guardar essas instâncias no model, ficando com uma serie de dados desnecessário no cliente.

A algum tempo atrás alguém perguntou no GUJ se o Hibernate fazia consultas (utilizando Criteria) excluindo propriedades vazias ( "" ).

Nativamente o Hibernate não dispoem desses recurso, porem utilizando Example podemos implementar PropertySelector para faze-lo exatamente como implementação do Example.excludeZeroes()

Exemplo de PropertySelector

Como utilizar

Esta semana tive um problema com uma query que teoricamente estava certa mas não estava exatamente fazendo o que eu queria.

A primeira opção para debugar é setar o atributo show_sql = true e verificar a query que está sendo montada. Outra otima opção que pode ajudar muito e economizar tempo, é setar a propriedade format_sql = true.

Porem em nenhuma delas você terá acesso as variáveis que estão sendo setadas na sua query. Caso você tenha configurado o log4j.properties provavalmente as variaves serão gravadas em arquivo ( caso você assim o tenha configurado ) mas dificilmente está será mostrada no console. Geralmente configuramos o log4j.properties para logar tudo (ALL) com isso dificultando nosso trabalho para encontrar alguma coisa quanto realmente precisamos. O projeto caveatemptor (projeto do livro Java Persistence with Hibernate) trás uma ótima sugestão de arquivo de configuração para debugar as querys que estão sendo geradas.

# Direct log messages to stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{6}:%L - %m%n

# Root logger option
log4j.rootLogger=WARN, stdout

# Log JDBC bind parameter runtime arguments
log4j.logger.org.hibernate.type=DEBUG

A grande sacada do arquivo acima e logar apenas as classes do pacote org.hibernate.type com isso você terá em seu console a query ( formatada ) e as variáveis que foram setadas na execução da mesma. Apenas o necessário para entender o que esta acontecendo!

Uma das funcionalidades do Hibernate é transformar os dados do banco em objeto (s) de acordo com as informações solicitadas, lhe poupando do trabalho de popula-los. Por padrão, o Hibernate popula todas os atributos do seu objeto, o que nem sempre é o desejado. Pense em um cenário no qual desejamos retornar ao frontend apenas os dados referente a identificação daquele objeto, como id e descrição, para popular um combo por exemplo. Não desejamos que o Hibernate retorne todos os atributos da classe gerando, assim, um trafego desnecessario em nossa rede.

Exemplificando, vamos imaginar que eu tenha uma classe de Produto que tenha dezenas de atributos. Não quero que o Hibernate popule todos eles, apenas o id e o nome do produto para enviar ao frontend. Para isso vamos utilizar 2 recursos: O setProjection, com a funcionalidade de projetar o que será requisitado na clausula select que, por padrão, sempre retorna os dados projetados como um array de objetos ao invés do próprio objeto (Produto); e o segundo recurso, setResultTransformer, que diz ao Hibernate como tratar os dados solicitados.

No exemplo acima, ao utilizarmos o método as("atributo"), criamos uma espécie de "alias" para o Hibernate saber em que propriedade ele irá "jogar" esse dado. Tal recurso é muito interessante quando desejamos selecionar dados de uma Classe e atribui-los diretamente a um DTO ou uma classe de relatório. O AliasToBeanResultTransformer pega todos os "alias" criados apartir do .as e atribui na classe que está sendo passada procurando pelo nome do atributo na mesma.

[update data="10/08/2007 14:15"]
Adicionado alias na query
[/update