I am trying to use a filter on a hibernate search. I read the section in the Hibernate Search in Action book where they implement a bridge to create a yes|no value based on a seperate part of the persistent entity and they they filter on it. When i try to do this i get no results from my query. As soon as i enable the filter, searches return nothing.

I put breakpoints in my bridge implementation's objectToString method and it is never called. I'm still wrapping my head around how this is supposed to be working but i figure at least the objectToString method has to be called at some point inorder for anything to be found in my search. From reading a few other posts around here i think that i may be narrowing in on the problem.

My DB is already built and indexed. I had assumed that objectToString on my brige would be called when i execute a search but i'm starting to wonder if this not how this works. Can someone familiar with this tell me, when is that method called? Do i have to manually rebuild or update the index before i can filter on the bridge value?

If so, is a call to session.index the solution? (I'm away from my dev environment at the moment and cant test this at the moment.)

You are really on the right track here. objectToString is only called in indexing time. Think about it, if you already have an existing index, but you add another searchable field or in your case a class bridge, you will have to update the index. It's just not there yet. So yes, you have to reindex.


Yes, that's the way to do it.

Have a look at the class bridge and especially the manual indexing section of the online manual. When indexing manually there are a few memory related things to consider. The online documentation covers that quite well.

--Hardy

Man, i was spinning in circles for hours last night trying to figure out what i was missing. This morning during my drive into work i kept thinking about the problem and it dawned on me that it must be a timing issue. Last night i was convinced that it was a configuration issue.

Thanks for letting me know that i'm on the right track. I'll check the doc for more on indexing and reply again if, i mean *when* i get this to work.

Ah, ok so i think that i'm moving in the right direction now. I got it working.

I guess the strategy now is figuring out what to index. I need to be able to generate the index on the fly i guess since what is being filtered is something that the user chooses at run time. I limited it to a few thousand results and it feels pretty fast so far.

So is that best practices for hibernate when you want to filter on a runtime defined subset of data? Just make an HQL query to narrow down to the set that you want to search in and then search using the new index?

I don't think that 'indexing on the fly' is what you want. In fact I am not even sure what you mean with this. Do you mean automatic indexing (index gets updated whenever
a entity gets created/updated/deleted)? This is a good first step, but it still does not mean that the user can search on 'anything' in the model. You still have to decide in forehand which fields to index. This is not something you can change at runtime.


We don't recommend to mix HQL with fulltext queries. Instead we recommend to index all data you need to your search and rely on the fulltext search only.

--Hardy

You know, after beating my head against the wall a bit more yesterday i realized what you just said. HQL and FullText should be treated separately. I wasnt looking at the problem correctly.

I'm beginning to realize that i need to build more indexes and create custom parametrized filters instead of trying to figure out how to inject HQL into the runtime search process.