Um objeto persistente, para o hibernate, é uma entidade que contem relacionamentos com outras entidades que juntos formam uma relação. Em diversas situações, na maioria das vezes no mundo real, essa relação se torna complexa quando existe a necessidade de relação com outras entidades, somado com o numero enorme de dados relacionados. Existem várias formas de obter essas esses dados relacionados, uns que permitem obter todo o conjunto de dados relacionados ao carregar o objeto (eager), outro no momento que a relação é obtida (lazy). Outras alternativas podem ser utilizadas em conjunto, como, as consultas nomeadas atreladas ao carregamento do objeto. Porém, apenas obter a lista de desses informações não é suficiente para a aplicação, fazendo com que o desenvolvedor utiliza consultas mais elaboradas com HQL ou criteria.

A forma como o framework monta as consultas é na maioria das vezes genérica e pouco intuitiva, fazendo com que o desenvolvedor opte por utilizar o SQL nativo, ou portar a consulta para uma Stored Procedure para construir uma consulta mais elaborada. É uma estratégia plausível quando a aplicação necessita de desempenho mas, isso tiraria a principal vantagem do framework; o acesso as relações que são representadas pelo relacionamento entre os objetos. Existe uma maneira muito simples de executar uma consulta SQL mantendo o relacionamento entre os objetos.

Para o framework, os objetos persistentes são de extrema importância. Quando o framework é executado pela primeira vez, ele adiciona uma série de funcionalidade nos objetos persistentes que permite realizar as operações em suas relações. A maneira com que o framework realiza essa tarefa é pela Instrumentação de código. A instrumentação nada mais de uma técnica de incluir alterações do código do programa mesmo após a sua compilação. O conceito pode ser semelhante com Reflexão e AOP, mas existem particularidades que tornam os conceitos bem distintos. Por ser um assunto muito pesquisado e com referencias em abundância, é um assunto para ser tratado outra hora. No hibernate, isso é feito através da lib ASM, que é um extenso conjunto de utilidade que permitem a plicar esse conceito nas classes escritas em linhagem Java.

Bom, para que o framework compreenda que o resultado de uma consulta SQL possa ser vinculado a um objeto é necessário que o retorno corresponda aos atributos do objeto, sendo que o objeto possa ser reconhcido pelo motor de consulta. Ex:


List<ClasseQualquer> planos = new ArrayList<ClasseQualquer>();
String queryStr = queryUtils.findValue(nome_da_query); //obtem a string de consulta
Query query = entityManager.createNativeQuery(queryStr, ClasseQualquer.class);

Obtendo um objeto Query configurado como acima, é possível realizar operações como essas abaixo:


List dados = instanciaObjetoQualquer.getDadosParticulares();

Esse simples macete pode ajudar bastente para obter objetos, que necessitem manter o acesso aos objetos relacionados, através de consultas bem elaboradas e com o desempenho do SQL.

Alem das funcionalidades do contexto de persistência também podemos contar com as funcionalidades extras que foram desenvolvidas pelo time de desenvolvimento, hoje pertencente a JBoss. Estou falando do pacote hibernate-tools.jar, contido no plugin feito para o eclipse, com o intuito de auxiliar no processo de configuração, mapeamento, importação de schemas e mecanismo de interpretação e execução de HQL. O link para download do plugin encontra-se aqui.

Tive a necessidade de fazer com que todo o schema fosse exportado para o banco de dados ao executar uma simples task do Ant. Funcionalidade que facilitaria muito a vida da equipe ao modificar o mapeamento das entidades do projeto, sendo apenas necessário executar a task para exportar as modificações para o SGBD. Para isso, desenvolvi uma task personalizada para solucionar esse problema. A task funcionava bem, mas chegou um ponto que não nos atendia. Portanto, vi que uma boa alternativa seria utilizar as tasks do hibernate-tools.

O pacote hibernate-tools.jar contem um conjunto de tasks que permitem a execução de procedimentos básicos de persistência através de simples tasks do Ant. As tasks são variadas, portanto é possível utiliza-las para; exportar schemas, gerar os inserts do mapeamento em um arquivo .sql, gerar os hbm.xml (se não tiver utilizando anotações) entre outras coisas. Mais um detalhe: o pacote hibernate-tools.jar é completamente independente do plugin.

A configuração para utilizar as tasks a princípio é simples, porém levei um tempo para acertar, já que meu projeto estava mal configurado e gastei muito tempo para descobrir o problema. Vou levar em conta que o seu projeto está devidamente configurado e fazendo todas as operações básicas (insert, update e delete) no banco de dados.

Para uma simples exportação do schema para o banco de dados, a primeira coisa que você deve fazer é adicionar o pacote hibernate-tools.jar no classpath do projeto. Após isso é necessário incluir uma referencia a classe que representa a task. Nesse caso, assim como está abaixo:

<taskdef name="hibernatetool" classname="org.hibernate.tool.ant.HibernateToolTask" classpathref="path.lib" />

Após isso, é necessário incluir um target que fará todo o trabalho sujo. Nessa target deve conter, dentro do <hibernatetool>, no mínimo as tasks <annotationconfiguration/> e <hbm2ddl/> para fazer o processo de configuração e a exportação de todas as configurações de mapeamento incluídas nas classes. Vamos ver o detalhe abaixo:


<target name="generate" depends="compile">
<hibernatetool destdir="${dir.build}/generated">
<classpath>
<path location="${dir.out.classes}"></path>
</classpath>
<annotationconfiguration propertyfile="${dir.out.classes}/hibernate.properties"  configurationfile="${dir.out.classes}/hibernate.cfg.xml" />
<hbm2ddl drop="true" create="true" export="true" outputfilename="../schema.sql" delimiter=";" format="true" />
<hbm2dao />
</hibernatetool>
</target>

Reparem que é necessário ter os .class incluídos no <classpath/> como descrito acima, pois é daí que vem todo o mapeamento dos objetos. A propriedade <annotationconfiguration/> representa as configurações do seu SGBD (hibernate.properties) e das classes persistentes (hibernate.cfg.xml). Claro que o arquivo cfg.xml pode conter as configurações do SGBD mas eu achei melhor separá-los.

A task <hbm2dll/> é o elemento principal do processo de exportação do schema. Nela é possível definir se, ao exportar o schema, irá dropar as tabelas existentes e criar uma nova estrutura e além do mais irá criar um arquivo .sql contendo tudo o que foi feito no banco.

Adicionei a task <hbm2dao/> apenas para mostrar o DAO gerado conforme as entidades geradas. Acredito que isso seja útil para os projetos que não utilizam o suporte aos DAOs do Hibernate do Spring.

Bom pessoal, esse foi um processo que me atendeu perfeitamente nos projetos que desenvolvo, portanto, segue a dica para os leitores. Chega de ficar mexendo nas propriedades hibernate.hbm2ddl.auto create-drop e escrever tarks personalizadas para essa tarefa.

[]s