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.

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 :))

Respondendo a ele: no way.

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.

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.