Hi

Basically we have a crazy domain model with crazy object graph. I have been looking at using Hibernate Search to perform free text search on this crazy domain model. Although I would ideally refactor the domain model it is not in the scope of this project. I was wondering if I could get some thoughts on whether what I would like to do is a good approach.

Say for example we have the following object graph

A
-- Set<B>
B has the following:
- name
- ref
- C
C has the following:
- name
- ref
-- D
X
Set<Y>
Y contains
name
ref
name
ref

What I was thinking of doing is rather than define lucene fields for each of the instances inside A I would create a custom bridge that would group certain things together for example I would create a CustomBBridge that would navigate through the entire object graph of B and dump the contents into a Lucene Field called ("B") and so on. This way my fields that i want to search on would look something like "B:test OR D:test" rather than having "B.name:test or B.ref:test Or B.c.name:"

Should I create a custom class bridge or should I use individual field bridges? Also is it ok to just index one entity for example A as I will always be returning A in the result set.

Any thoughts or advice would be grateful.

Cheers

P.S. I hope this made sense!

Hi,

Your approach would certainly work. A single ClassBridge or several FieldBridges should to the job. It is also ok to just mark class A as indexed.

The drawback of your solution is that your are limiting the ways you can search your index. Having separate field names gives you much more control over your queries (using Lucene's BooleanQuery) and it will be easier to change these queries over time.

That said, if you have a good reason why you want to index into one single field, go for custom bridges.

--Hardy

The main reason for putting alot of the data a group of fields is because I don't want to create a massive search string to query for example due to the craziness we would have something like

a.bs.ref:test OR a.ts.ref OR .....

I have decided to include more refined fields for any internal search requirements or security filtering.

Thanks for your response.