Hi,

I've successfully deployed HSearch with our spring/hibernate/jpa environment and it works as advertised. However, I'm missing a key point.

We rarely delete, we toggle statuses. Using lucene directly we of course control the de-/indexing and those items are removed from the index when their status goes "deleted". But what's the best practice for handling this with HSearch? I know I could store the status on the document and modify the query code to omit it in search results but that would clutter up the index needlessly. And I'd rather not lose the automatic indexing features of HS. Are there hooks I'm missing to facilitate this? TIA.

I would try the delete flag solution first, I'm pretty sure it's not that bad and it would allow you system to search deleted elements as well.

Otherwise, there is no easy way to achieve what you want. Hibernate Search is flexible enough however to plug arbitrary backend processors. Today there is a Lucene backend processor and a JMS backend processor.

I'm pretty sure you can subclass or fork the LuceneBackendProcessor(Factory) to delete when some objects are updated.

Once you've done that, you can set the processor factory used through this property:



If it's not enough, you can plug an entirely different system right after the event model.

It's a Worker implementation and can be configured using



The second solution would require much more qurk I imagine (not sure).


Let me know how it goes, I am interested to see how flexible the extension points are.

Hmm, we just wandered into this very same problem (or need) at our project. Actually this is a very common use case, where your indexed entity might be going through some transitions (although persisted) before you are ready for it to be indexed. Think "'blog item' not-yet-published", or (in our case) "added 'review' not yet granted by our back-office" for instance.

As I understand your answer above this is not available in out-of-the-box Hibernate Search but could (possibly) be handled by extending at the available extension points.

Wouldn't it be reasonable to be able to specify a predicate class in the @Indexed-tag. The callback-method on the predicate class is then served (by HSearch) the Entity about to be automatically indexed and will answer true/false whether the entity fulfils the requirements for it to actually be indexed. What's your opinion on this Emmanuel? Good or bad idea?

If the flag solution does not work for some reason we can check this feature, but today I still think the filter or lucene flag is the best approach.

I have deleted flag on Character field. Do I need to write my own StringBridge for Character field? (I see no such bridge in HS)

Yes, making your own StringBridge is really simple and a clean solution.

Otherwise you could use a String instead, configuring the @Column to map it as a Char on the database tables, but this could lead to problems if you use set the value to something longer than 1 char. Use it with a @Length validator in that case.

I made such StringBridge in one minute ;)

What about more advanced filtering? For example I set max results to 1000, but I need to filter results in complicated way (algorithm for it is complicated)

For example I usually don't see deleted records, but if I have special administrator rights and those records are children of record I own, I can see them

I can post-filter my results, but then I can receive less the 1000 records despite having in index much more records that fit.

copied from Hibernate Search documentation, chap 5.3. Filters:



I love this API; isn't this good for you?
You may define all filters you want, nearly as simple as defining your own StringBridge. They will even improve your performance, as sub-selects will be reused as soon as a bug is resolved.

please open new threads for new arguments.

regards,
Sanne

I have problem with Bridge. I use BLOB field to store different types of document like PDF, DOC etc. How Bridge can know what type of document it processes? I can give bridge a parameter but it's constans.

So you have another field containing the actual type?
Use the Bridge at class level, so you can look at both fields.

Well, you can start reading the blob and discover the type, this is how its done usually.

We should add the characterBridge to the distribution, let's open a JIRa issue