Ontem participei de uma session sobre a nova funcionalidade do FlashBuilder – Mode-Driven Development e gostei bastante da produtividade que a ferramenta proporciona. A versão atual do FlashBuilder ainda apresentou alguns bugs mais fizemos 4 cadastros no flex em 1:30h, sem escrever uma linha de código no back-end. Não cheguei olhar a fundo o código gerado mais pude perceber que a ferramenta mantém o código customizado após uma mudança de modelo e regeração do código.

No estilo drag and drop, ao mesmo tempo que você cria o modelo, o FlashBuilder vai escrevendo suas Entidades, Serviços e tudo o que é necessário para fazer a integração com o back-end. Destinations ou Assemblers(configuração de server BlazeDS ou LCDS) são criados em tempo de execução para cada entidade e também um arquivo xml que representa o modelo criado onde você pode mudar as configurações de banco de dados, mapeamento de tabela e outras coisas.

Como utlizamos o LCDS, tivemos a possibilidade de ainda ter DataManagment funcionando com Hibernate + Paginação e atualização de dados automática com RTMP tudo “automagicamente”!

Vale a pena olhar o vídeo de exemplo:

Em projeto recente foi necessário requisitar objetos em um banco legado os quais não eram entidades gerenciadas pelo Hibernate mas sim por outro software.

Mapear estes objetos como novas entidades e criar Criteria’s ou HQL’s com base em SQL’s prontas enviadas pelo cliente seria custoso. Como o projeto não era resposável por manter estes objetos sincronizados com o banco, seria interessante utilizar as SQL’s prontas em beans não gerenciados pelo Hibernate.
Leia o artigo completo »

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!