Eu não testei e, sinceramente, não sabia da existência até alguns minutos atrás mas o me parece cheio de possibilidades tentadoras! O post do Emmanuel explica em linhas gerais, assim que sobrar um tempo por aqui eu quero fazer uns testes…
Cada vez menos existe a necessidade de se sequer pensar na persistência utilizada (i.e. Banco de Dados Relacional) para aplicações. Relatórios e transformações pesadas de dados são uma desculpa interessante mas podem ser devidamente isoladas do núcleo transacional da sua aplicação.
Parece interessante mesmo, você pensa em tentar usar esse trêm com o FDS?
Eu também achei interessante essa integração entre Hibernate e Lucene, quando soube.
O problema é que normalmente (bem, o *meu* normalmente :)), a granularidade de ‘documentos’ é muito diferente da dos ‘objetos’. Um usuário quer procurar livros cujo nome do autor contém ‘Fowler’ e o assunto contém ‘pattern’. Porém, Livro, Autor e Assunto são classes diferentes, e seguindo a recomendação, seriam representados por documentos diferentes, residindo em índices diferentes.
Que eu saiba, o Lucene não tem ‘join’, então você teria que pegar os autores com ‘fowler’, os assuntos com ‘pattern’, e verificar quais livros dos autores batem com os dos assuntos.
Se você fosse fazer a indexação na mão, autor e assunto seriam apenas dois campos do documento que representa o livro, e assim, o cruzamento das informações fica bem simples.
Não encontrei nada na documentação sobre uma possível flexibilidade de mapear propriedades de entidades relacionadas para campos do documento ‘principal’, mas pode ser que seja só sono :)
Sei lá. Eu tenho essa mania de, quando vejo uma tecnologia nova, pensar nos ‘corner cases’ primeiro, onde ela vai começar a falhar. Mas nesse caso, acho que nem chega a ser exceção, mas sim a regra.
Oi, Ronald,
na verdade acho que você está querendo uma search engine e não é essa a propsota do projeto. Passei pela adoção de uma search engine em um dos meus projetos atuais e como um amigo meu já experiente neste ramo sempre me disse é um mundo a parte, não pense em joins.
Indexação e busca não funcionam como bases relacionais onde tipos são criados com joins (isso tornaria o processo extremamente inceficiente, acho que é a maior limitação) mas sim com modelos estáticos. Quando você utiliza uma search engine elabora a estrutura de dados que precisa consultar e a utiliza para sempre, ou ae mudar e reindexar tudo.
Esta limitação também existe, por outros fatores, com objetos, Estrutturas relacionais são mais dinãmicas na formação de novos tipos que objetos, aliás este é um artigo que pretendo escrever ainda.
Com o Hibernate Search, ao que parece, você pode fazer ao menos uma primeira camada de busca nos objetos de domínio, o que é bem diferente;
Mas bem, essa é a teoria, ainda não brinquei.
Aliás, o meu amigo em questão é o louds, Rodrigo Kumpera, autor do primeiro comentário.
Respondendo a ele: no way.
O que eu não entendi ainda é qual seria a utilidade desse recurso.
Digo, para as consultas triviais (sobre as propriedades de uma única entidade do domínio), não vale a pena usar o Lucene, já que um select (em HQL, no caso) já dá conta do recado perfeitamente, já é simples e rápido o bastante.
As consultas ‘interessantes’, como a do meu exemplo anterior, que envolvem mais de uma entidade, pelo que eu entendi não são possíveis (coisa que o ‘join’ faz num banco relacional), forçando-o a fazer X consultas e cruzar os dados na mão.
A única situação em que a coisa vale a pena é em consultas textuais, onde o ‘LIKE’ não serve, ou que a performance do lucene é muito melhor que a do banco. E ainda assim, ou os dados ficam todos em uma única entidade, ou tem que valer a pena fazer o cruzamento na mão.
Então, um search engine é um mundo à parte, o lucene entra onde, como um substituto mais complexo (+1 tecnologia) e menos poderoso de um select?
Bem, mas cada um com seu cada um. Cada pessoa convive com problemas diferentes, e alguém deve ter essa necessidade (se não, não tinham feito, né). Até EJB é justificável em alguns casos! Eu só queria conseguir entender a utilidade desse recurso (vai que eu topo com esse problema algum dia :))
Tetsuo,
Procure na documentacao do Hibernate Searh, pela annotation @IndexedEmbedded.
Voce nao precisa ter indices separados para cada classe, voce pode manter seu modelo normalizado e criar um indice unico.
No seu exemplo, voce teria uma entidade Livro que possui uma entidade Autor e outra Assunto.
A entidade Livro estaria mapeada com @Indexed, e as suas propriedades assunto e autor com @IndexedEmbedded.
Assim voce terá um indice unico representando suas 3 entidades e nao 3 indices e fzendo “joins” na mão.
Se voce abrir o indice com o Luke verá q os campos criados ficaram mais ou menos assim:
livro.preco,
livro.assunto.descricao
livro.assunto.tema
livro.autor.nome
livro.autor.sobrenome
etc… udo no mesmo indice.