As consultas que são utilizadas pelo Envers são semelhantes ao modelo criteria, recurso nativo do Hibernate. O framework permite a consulta em duas dimensões: a primeira, horizontal, corresponde ao estado do banco de dados em uma dada revisão. A  segunda, vertical, são as revisões na qual as entidades são modificadas.

A documentação afirma que a principal limitação, quando se trata de queries, são as consultas com relacionamento  entre os objetos, recurso não suportado previamente pelo framework. Outro fator negativo é o fato das consultas aparentarem ser mais lentas que as consultas sobre os dados ditos “vivos”, ou melhor, os dados das entidades na qual o banco de dados foi projetado. Porém, é um recursos interessante, já que o framework da uma certa facilidade para a realização das consultas. Agora, nada impede de vc utilizar sql nativo para obter os dados de auditoria. Basta apenas compreender o schema e o mapeamento das chaves.

DETALHES DE USO

Os recursos disponíveis para a elaboração de consultas sobre os objetos de auditoria são simples de serem utilizados. A princípio é necessário obter um objeto chamado AuditReader de um EntityManager para poder realizar as consultas. A forma de obter tal objeto é descrita abaixo:

AuditReader reader = AuditReaderFactory.get(em);

Através desse objeto é possível utilizar os métodos de consulta existente na interface, ou melhor, utilizar os recursos, mesmo que capados, de criteria sobre os dados de auditoria, como abaixo:

List result = reader.createQuery()
    .forRevisionsOfEntity(classe, false, false)
    .add(AuditEntity.id().eq(id))
    .getResultList();

Só uma observação; na documentação do produto, apesar de bem branda, está incompatível com os recursos disponíveis na versão 4 do hibernate. Pra quem ainda não sabe, o envers foi incorporado a arvore do hibernate para formar um produto apenas. Com isso, a documentação oficial está desatualizada com release principal do produto. Porém, as consultas são funcionais. Você pode utiliza-las como modelo para a elaboração de suas consultas.

DADOS DE AUDITORIA PERSONALIZADOS

Existe um recurso que foi muito útil para elaborar uma determinada consulta. Por padrão,  as tabelas _AUD, geradas pelo framework, não armazena a data da alteração e nem mesmo quem alterou. Claro, isso, na maioria das vezes, fica por conta da implementação. Porém, caso seja necessário incluir dados amais sobre os objetos auditados é possível armazena-los em uma entidade sem a interferência no mapeamento do seu sistema. Isso é possível utilizando dois recursos: a anotação @RevisionEntity em conjunto com a interface RevisionListener. A classe que for anotada com @RevisionEntity deverá ter duas propriedades como equisito:

• um in ou long, anotado com @RevisionNumber, frequentemente um campo com valores gerados automaticamente

• um long ou um java.util.Date anotado com @RevisionTimeStamp, que seria mais um atributo preenchido pelo Envers.

Dica: caso não queira incluir os atributos de pré-requisito, utilize a anotação default: @DefaultRevisionEntity. Isso elimina completamente a necessidade de criação dos atributos de pré-requisito.

Após isso, é possível adicionar qualquer atributo a mais para suprir suas necessidades. Esses atributos serão persistidos como uma entidade normal. Tanto que, será necessário incluir a classes que armazenará esses atributos no persistence.xml.

O processo de criação aparentemente parece que está ok. Agora a pergunta é: Como esses dados serão armazenados? Isso é feito através de um listener que contem um método que é executado a cada modificação de uma entidade auditada. Portando, o trabalho de setar os valores fica por conta do programador. Abaixo está o listener utilizado como exemplo ilustrado na documentação oficial:

public class ExampleListener implements RevisionListener {
    public void newRevision(Object revisionEntity) {
        ExampleRevEntity exampleRevEntity = (ExampleRevEntity) revisionEntity;
Identity identity = (Identity) Component.getInstance("org.jboss.seam.security.identity");
        exampleRevEntity.setUsername(identity.getUsername());
    }
}

Fica ao critério do programador quais são os dados que serão armazenados e quando. Portanto, em um exemplo que fiz pra testar esses recurso inclui apenas o login do usuário informando quem foi o autor da alteração:

public class EnversRevisionListener implements RevisionListener {

     @Override
     public void newRevision(Object revisionEntity) {
          Map<String,Object> session = ActionContext.getContext().getSession();
          if(session != null) {
              ApplicationUserElementSession userSession = (ApplicationUserElementSession) session.get(Constants.APPLICATION_USER_SESSION);
              LoginRevEntity exampleRevEntity = (LoginRevEntity) revisionEntity;
              exampleRevEntity.setTimestamp(new Date().getTime());

              if(userSession != null)  {
                  User userAutenticated = userSession.getUserAutenticate();
                  exampleRevEntity.setUsuario(userAutenticated.getLogin());
              }

              else {
                  exampleRevEntity.setUsuario("new_user");
              }
          }
     }
}

A dica transmitida nesse post extrapolou um pouco. Foi além de consulta para auditoria personalizada. O que foi passado aqui foi apenas uma introdução, ou melhor, um subconjunto dos recursos que precisei para desenvolver meus métodos de auditoria. A documentação, apesar de desatualizada, é bem direta e simples de ser seguida. Porem, aconselho vc baixar o código do hibernate pelo github. No raiz vc vai encontrar o diretório hibernate-envers. É lá que está a nova versão do envers que é distribuída com o framework.

Soluções de auditoria podem ser encontradas em todas as linguagens através de frameworks e tutoriais que solucionam um determinado contexto. Assegurar um modelo comum tem sua parcela de dificuldade mas, de modo geral, é possível adquirir muita vantagem nesse ponto.

Um tempo atrás, me deparei com uma situação para auditar tudo o que acontece na camada de persistência, com o objetivo de gerenciar todo o conjunto de modificações de objeto que continham valores monetários. Os gerentes queriam saber a procedência de alteração de uma série de elementos que foram armazenados, inclusive quem os armazenou e qual foi a URL executada para remove-lo. Nesse caso, foi necessário desenvolver uma série de listeners para realizar a leitura de elementos contidos na sessão e armazena-los. Porém, quando se trata de aplicações corporativas, normalmente estão espalhadas em outros servidores, normalmente provendo serviços que outras aplicações acessam. O maior problema disso tudo é que armazenar o histórico de um objeto em uma outra base de dados, normalmente com o auxílio desses serviços (seja EJB, Web Services ou RESt) é um trabalho a mais, gerando um deley desnecessário para a aplicação. Em muitos casos, o armazenamento dos logs no schema utilizado pela aplicação minimizaria consideravelmente o fator tempo utilizado para o complemento da transação .

No mundo Java, o framewok predominante é o Hibernate. É muito difícil projetar um aplicação que não utilize o framework para mapeamento objeto-relacional da linguagem Java. É um excelente framework, na minha opinião, o mais bem sucedido quando se trata de funcionalidades providas por frameworks. A auditoria realizada com esse fremework pode ser feita utilizando listeners e que executam call-backs dispondo de eventos que podem executar ações antes ou depois da persistência de objetos. Ainda assim, a dificuldade e o tempo de desenvolvimento de uma solução mais viável e rápida fica a desejar.  Dessa forma, para preencher a lacuna, utilizaríamos recursos de aspectos do Spring para uma coisa mais elaborada. Manter uma solução como essa, em certos pontos, despadronizada e mal documentada, se tornaria um caos. Normalmente tratativas reais no ambiente onde se desenvolve o software.

Hoje em dia, acompanhado desse framework está o Envers, que é um framework de auditoria nativo do Hibernate, tanto que ele vem junto com o pacote distribuído no site do produto.

Resolvi testar o Envers em uma aplicação piloto para conhecer as funcionalidades de auditoria provida por esse framework. Logo de primeira, fiquei impressionado com a facilidades de integração com o Hibernate. É só incluir a lib e utilizar as anotações. Só isso e nada mais. Porém, o framework tem suas particularidades. Para cada entidade que deseja auditar é necessário incluir uma anotação, seja ela no atributo em questão ou no todo da classe para anotar todos os atributos. Após rodar o projeto, no momento da atualização do schema, será criada a tabela de auditoria como o complemento do nome “AUD”.

 Em objeto de classe que for anotada com @Audited, será gerada uma estrutura semelhando ao desenho acima. As tabelas “AUD” armazenam os atributos da classe que foram anotadas.

Nem sempre o que o framework oferece é o suficiente para executar por completo nossos requisitos de negócio. De acordo com a configuração default, foi oferecido ao desenvolvedor registrar as modificações dos objetos com revisões. Porém, em algumas situações, talvez necessitamos de um conjunto de informações mais rico. Ou melhor, precisamos registrar a data que o objeto foi modificado, por quem e qual o caminho que o usuário percorreu até concluir o conjunto de funcionalidades.

Para isso, será necessário a inclusão de dois elemento para que possam trabalhar em conjunto. A anotação @RevisionEntity e o listener RevisionListener.

A anotação permite escolher uma classe que representará uma entidade que irá conter os atributos a mais necessários para serem armazenados. O listener incluirá de escutar a modificação realizada no objeto e executar um método para executar alguma programação que, na maioria das vezes, seria uma extração de informação de algum objeto que está na sessão ou de um método de armazenamento temporário de objetos. Isso ficaria mais ou menos assim:

A cada modificação realizada o método newRevision é executado, podendo aí utilizar do mecanismo para preencher os campos da entidade auxiliar.

Esses são apenas recursos que considero o mais básico possível que uma aplicação de médio porte pode ter. O Envers possui mais recursos para armazenamento, cujo conteúdo está disponível na documentação do produto.

As consultas são um caso a parte. O Envers utiliza o conceito de revisão, uma ideia bem semelhante ao Subversion, fazendo com que cada modificação realizada no objeto gere uma nova revisão. A revisão é armazenada juntamente com os dados que foram modificados, inclusive o seu tipo de modificação que foi realizada.

A ideia dos tipos de transação são bem claros quando olhamos o dados armazenados. No teste que eu fiz no MySQL podemos ver o campo REVTYPE. Onde é armazenado os tipos de modificações realizadas no objeto:

Quando instalamos o pacote, normalmente ele é encontrado do diretório /usr/local/mysql/support-files. Aqui é possível encontrar uma série de scripts que podem facilitar muito a vida de que utiliza o mysql. Inclusive o arquivo mysql.server que contem as diretivas para iniciar, reiniciar e parar. Normalmente tentaria-mos encontrar esses arquivos no diretório /etc/init.d/.

Esse erro acontece que nas libs do JBoss já existe a mesma biblioteca. Quando é feito o deploy, ou executado standalone, esse erro acontece. Não adianta remover a lib do classpath da aplicação. Pode ater dar certo mas, se sua aplicação depende dela, talvez os testes automatizados não sejam executados corretamente.

Para solucionar esse problema em uma aplicação web simples, é necessário informar ao JBoss que essa lib é necessária para o projeto. Para isso, é só incluir a linha abaixo no arquivo MANIFEST.MF: Dependencies: org.dom4j. No momento do deploy o JBoss ler esse arquivo para tentar encontrar diretivas utilizadas para gerenciar o ClassLoader da aplicação e gerenciar a dependência de módulos.

Espero ter ajudado.

Nesse caso, a melhor ferramenta é a nossa cachola. Encontrei nesse blog um número repleto de dicas para solucionar os problemas de Anti-Pattern que utilizamos no dia-dia. Desde dicas de performance até soluções para determinados problemas. Vale a pena dar uma olhada. Odi’s Blog.

Terminei de ler o livro essa semana e queria escrever alguma coisa sobre o que eu li. Também expressar  minha opinião sobre a figura de Steve Jobs.

Acredito que não exista nada melhor do que olhar pra trás e ver seus feitos, criações, ideias que foram concretizadas. Também, acredito que deve ser a mesma coisa quando olhamos em volta, no próprio presente, e vemos os frutos de nossos esforços que foram feitos no passado. Uma vez, ao ler a biografia de Albert Einstein, li uma frase fabulosa; “Quando olhamos para uma fórmula, nos deparamos com números, constantes e símbolos para que nos trás um determinado resultado. Mas, muitas coisas se escondem através dessas formulas, noites em claro, um certo distanciamento dos seus familiares, críticas e esforço pra prova-las para pessoas incrédulas, lágrimas e um pouco de cabelos brancos.  Se conseguíssemos olhar profundamente em cada criação humana poderíamos ver a dor e o sacrifício, que, são sempre maiores que o mérito atribuído pela criação”.

A biografia de Steve Jobs contada por Walter Isaacson teve um grande sucesso em alcançar exatamente o ponto do sacrifício, foco e a dor que envolvem uma criação. Em cada ponto da obra existe conflitos e principalmente a explosão do temperamento de Jobs em diversas situações e momentos, no trabalho, família e amigos. Mesmo assim, em alguns momentos, são feitos que contém méritos, pois, ele conseguia tirar o máximo dos seus funcionários. Coisas que eram declaradas como impossíveis de serem realizadas, eram feitas e no tempo estabelecido por ele. Realmente, devia ser uma coisa estressante trabalhar a base do grito e com um líder que tinha uma constantes explosões de personalidade.

Muitos podem afirmar que Jobs era um tremendo de um mal caráter salafrário sem coração. Sim, depois que eu li sua biografia é essa a conclusão que tirei. Até mesmo de leitura das primeiras cinquenta páginas é possível tirar essa conclusão. Mas a questão é: porque isso tudo? Porque ele teve tanto sucesso? Bom. Eu nunca saberei responder porque eu não trabalhei com ele, mas a minha suposição é que: ele utilizava a abordagem do chicote pra tirar todo o potencial de uma pessoa. Se ele visse potencial naquele indivíduo ele iria descasca-lo até conseguir o que queria. Isso não é uma boa abordagem, mas funcionava com ele.

Enquanto estamos tentando diminuir o máximo possível o tempo das reuniões, as suas duravam no mínimo três horas. O fato de ser meticuloso e da necessidade de ter o controle da situação por completo levava ao limite  as pessoas de sua confiança. Uma coisa é certa, o mesmo olhar que via no Senna quando ele conversava com os engenheiros e em suas reuniões. Isso é possível ver em Jobs nos poucos momentos que se deixou filmar trabalhando. A seriedade e a atenção, quase que hipnótica, era perceptível em suas feições quando travam de assuntos do seu interesse. Para Senna, isso era imprescindível, pois tinha um carro inferior aos demais, portanto, era necessário conhecer seus limites ao máximo para poder lava-lo a vitória. Para Jobs, sua ânsia  de criar produtos e, ao mesmo tempo,  a vontade de derrubar IBM tornou-se seu principal elemento de motivação.

A Paixão. Isascson, em muitos pontos do texto, cita a paixão como ponto fundamental para a motivação de Jobs. Acredito que até mesmo para o seu time. Ele conseguia ver isso nos demais. Olhava nos olhos dos seus de seus funcionários tentando encontrar a paixão por produzir coisas novas, de tirar o que tinha em sua cabeça e pode materializar em alguma coisa inovadora. Ele conseguia fazer isso como ninguém.

Uma das coisas que Jobs sempre falava era de ter amor e orgulho do que se fabricava. Isso não está na biografia, mas no livro “A Cabeça de Steve Jobs”; quando ele voltou para a Apple, se deparou com inúmeros funcionários falando mal dos produtos que foram criados. Isso deixou Jobs com uma raiva enorme e sempre que escutada isso de algum funcionário ele “estevava” (termo criado pelos funcionários da Apple quando das humilhações que eram feitas em público aos seus funcionários) o sujeito lá mesmo. Só que, em várias reuniões ele mesmo afirmava que os produtos que a Apple fez, até o momento que ele estava fora, era tremenda porcaria. Mas o que ele queria despertar nas pessoas era o amor. A paixão e o orgulho ao ver uma coisa concluída, em fazer parte de um time de estrelas. Acredito que era isso que ele sempre quis enfatizar.

Normalmente, quando fazemos alguma coisa de valor, seja a mínima possível, gostamos sempre de receber um parabéns, nem que seja um simples tapinha nas costas seguido de um “bom trabalho”. Nesse ponto, não tenho do que critica-lo. Quando Jobs brilhava, seu time pegava carona no seu no seu brilho. Quando um trabalho era bem feito, ele sabia reconhecer o esforço. No texto do Isaacson, ele afirma que Jobs mandou gravar o nome de todos das sua equipe a parte interna do Macintosh, afirmando que aquela era a assinatura do artista.

Em diversos pontos, isso segue com controvérsias. Existem algumas histórias que põe abaixo toda essa afirmação acima. Entre as mais famosas, inclusive contado pelo próprio Woz, foi a redução de uma placa de circuito que Woz fez para Jobs. Jobs levou para a Atari, a empresa que trabalhava na época, e ganhou os méritos e o prêmio em dinheiro devido a esse feito e não contou e também não repassou nada para Woz. Outros histórias, está nas idéias sobre o design dos produtos. Essas reuniões eram constantes que tinha com Ive, porém, em muitas situações, as idéias que Ive tinha Jobs afirmava que eram dele. Não repassava o crédito sobre tais fatores. Muitos vão dizer que era assim que ele era, mas, muita coisa poderia ser feita de forma correta por ele. São pontos que não são importantes, acredito que os devidos méritos poderiam ser dados, já que, os acrescentaria muito para a sua equipe.

Depois do seu diagnóstico do câncer, até o seu tratamento, ficou perceptível a sua doença, principalmente pela rápida perda de peso. Porém, uma coisa de se admirar em pessoas complexas, principalmente em Jobs, é o fato da doença não o deixar-se abalar. Era perceptível que havia alguma coisa errada. Porém, poucas vezes se deixou abalar. Em suas apresentação, apesar da perceptível perda de peso, ele nunca expôs seus problemas de saúde a público. Até o ultimo momento que suas forças permitissem ele trabalhou. Se a empresa que ele criou é dessa forma, acredito que seja por essa força que foi reerguida está onde está. A cara da Apple e Pixar está um Jobs, carrancudo, mal criado, agressivo, astuto e falastrão, mas funcionou (It’s work).

Só mais uma coisa (Just one more thing). O fato da teimosia de prevalecer o controle e da convergência de hardware e software o levou a batalhas estremas. No início da Apple, ele levou isso até o seu limite. Após a fundação da NeXT, seu lema continuou. Quando voltou para a Apple, levou isso com sangue. Ao olhar para trás, quando o mundo corria para a liberdade do software para ambientes padronizados e sem controle, Jobs acreditava que o controle estava na convergência do hardware com o software. Vendeu poucos produtos e perdeu mercado, porém, seus produtos funcionavam e bem. Utilizar a convergência, ter o controle do início ao fim da experiência do usuário no uso do computador deu certo para Jobs. Nos últimos dias de sua vida até Bil Gates reconheceu seus feitos, porém, afirmou que isso tudo funcionava apenas com Jobs. Jobs discordou. Mas na minha opinião, Gates estava certo. Acho que poucos teriam a teimosia de manter esse pontos integrados com tanto vigor.

A informática é  uma ciência ainda jovem. Vemos seus protagonistas irem embora a cada ano que passa. Pessoas boas, como Dennis Ritchie, acredito eu como principal colaborador dessa ciência. Porém, temos que dar méritos também a esse louco. Criar produtos, cujo termo mais propício para descreve-los seria “humanizados”, que eram sucesso a cada lançamento não são feito por pessoas comuns. Não que eu diga que Jobs era uma pessoas diferente de nós, mas o que nos difere de pessoas como essas é que a paixão estava nas coisas que ele fazia. A vontade de mudar o mundo “Pensando Diferente” são pontos de méritos.

Recentemente, foi disponibilizada a relase 2 do versão 7 do AS, porem, a questão a ser tratada é a reformulação da estrutura do produto em comparação com as versões anteriores. O time de desenvolvimento praticamente refez todo o core do servidor, modificando desde a estrutura de carregamento das classes (classe loadin) até a forma de gerenciamento de dependência.

A interface de administração, apesar de não ser o forte deles, está mais limpa e direta. Através dele é possível ter total informação do que está instalado no servidor, datasources, módulos, dependências,  web services, etc. Lembro que no JBoss 5/6 havia uma interface que mostrava os webservices que estavam disponíveis na aplicação. Nessa versão, esse tipo de informação está disponível na própria interface de administração.

- VELOCIDADE AO SUBIR

Alguns pontos que se destacaram logo a primeira vista, entre esses, o mais perceptível é a velocidade que o JBoss é iniciado. Ao verificar os detalhes, me deparei na principal mudança ocorrida no núcleo do servidor. Ele está trabalhando inteiramente com OSGI, ou seja, no momento do boot o servidor sobe apenas os módulos necessários para tal. Esses elementos são lidos no arquivo de configuração domain.xml ou standalone.xml respectivamente.

Isso justifica o fator da velocidade de carregamento. Porém, quando for necessário incluir mais um módulo que sua aplicação necessite, um REST ou um Web Service tradicional por exemplo, será necessário editar o arquivo de configuração para que o módulo seja incluso.

- OS MÓDULOS

Essa informação está bem explícitas nos arquivos de configuração das instâncias, logo na primeira sessão está presente as extensões necessárias para o funcionamento da instância. Mais embaixo, quase no fim do documento, estão os módulos.

Os drivers de conexão JDBC são também tratados como módulos. Portanto, para utilizar um driver de conexão com um determinado banco de dados, será necessário incluí-lo como um módulo e importa-lo do projeto. Isso é feito criando uma hierarquia de diretórios, adicionar o jar do driver no diretório main, conforme o padrão, e criar um documento de descrição do módulo em questão, como o exemplo abaixo:

- INSTÂNCIA

A versão 7 suporta uma característica muito útil que para organizar as aplicações. O conceito de instância. Quem já trabalhou com o Oralce Application Server (hoje em dia Web Ligic) e com o WebSphere sentia bastante falta desse conceito no JBoss para efetuar configurações específicas de uma aplicação específica.

No primeiro momento, a opção por executar o jboss no modo standalone, mesmo em ambiente de produção, torna-se a melhor opção pelo fato da facilidade, ou melhor, ser um processo parecido como o que tinha nas versões anteriores.  Isso não quer dizer que não funcione, pelo contrário, funciona perfeitamente, tanto que temos aplicações rodando com essa configuração.

Acredito que, além da quantidade de recursos existentes nessa nova versão, uma outra característica que vem implícita com o servidor de aplicação, mesmo nas versões anteriores, é a simplicidade. A curva de aprendizado para configurar e disponibilizar um servidor de aplicação JBoss é bem baixa.

O JBoss apresentou um servidor de aplicação robusto e simples de utilizar. Acredito que com essa ultima versão deixou muito dos seus usuários otimistas, mesmo com as mudanças drásticas realizadas em sua estrutura.

]]> http://www.nelsonalone.com.br/2012/01/22/jboss-7-reformulacao-completa/feed/ 0 http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/ http://www.nelsonalone.com.br/2011/09/26/twitter-storm-no-github/#comments Mon, 26 Sep 2011 15:08:18 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=595

(More)…]]> A equipe de desenvolvimento do Twitter disponibilizou nessa segunda a ultima versão do storm. Pra quem não conhece, assim como eu a duas horas atrás, é uma API do Twitter, desenvolvida pela BackType, utilizada para solucionar problemas de processamento em tempo real com tolerância a falhas.

Referências abaixo:

Artigo na Infoq: Link

Repositório no GitHub: Link

Wiki: Link

Fuçando na internet, encontrei o blog do Fabien Sanglard’s que transcreve todos os passos para rodar os fontes do Quake II. Em seu post são descrito os passos necessários para compilar e executar os fontes, contem também os detalhes do módulos, arquitetura e etc. O post está mais completo que o meu sobre o Quake III. Vale a pena dar uma olhada.

]]> http://www.nelsonalone.com.br/2011/09/22/codigo-do-quake-ii/feed/ 0 http://www.nelsonalone.com.br/2011/09/22/hibernatejpa-%e2%80%93-utilizando-sql-sem-perder-o-vinculo-dos-objetos-relacionados/ http://www.nelsonalone.com.br/2011/09/22/hibernatejpa-%e2%80%93-utilizando-sql-sem-perder-o-vinculo-dos-objetos-relacionados/#comments Thu, 22 Sep 2011 16:51:37 +0000 nelsonsozinho http://www.nelsonalone.com.br/?p=581

(More)…]]> Não há dúvidas de que o hibernate é um excelente ORM, se não o melhor que há no mercado. Porém, muitas pessoas, satisfeitas com os procedimentos iniciais de aprendizado do framework, não se dão conta das demais funcionalidades disponíveis para o desenvolvedor. A lista é vasta, confesso que posso não conhecer a metade, mas alguns dias atrás, uma dessas funcionalidades me ajudou muito.

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.