We're upgrading to H.Search 3.4 and it seems that we have hit an incompatibility issue with our old code.

In our domain model we have 'public' and 'private' photos. Public photos' metadata must be indexed and available as fulltext search results on the public web page, private photos don't. We have around 100.000 public photos and 500.000 private photos, so adding them all to the index is not a good option.

That's the code that worked perfectly for the situation stated above and that doesn't work anymore with Search 3.4.0.CR2 and H.Core 3.6.3.Final:

Our custom FullTextIndexEventListener that was checking if the updated entity was "public" or "private" and decided if must be added to the index or not:



hibernate.hbm.xml <event/> section:




The exception raised is:




Any ideas on how to extend FullTextIndexEventListener in Search 3.4 and Core 3.6.3 to selectively add entities to the lucene index? or alternatively how to do the same without having to give up using listeners? doing it manually is tedious and error prone since we should add code to every DAO updating photos.

Many thanks for your help/ideas

Jordi

Hi,
we're having intentions to make the listener final, that's been in the comments for a long time now, as people have lots of issues when extending it; having it extensible was never an intention.

As you noticed, the constructor is now throwing an exception to make sure people notice that it's not intended to be registered by configuration.. so right I could as well make it final right now.

About your workaround: are you aware that when persisting a new entity it's going to trigger a different event which you're not skipping? And you're not avoiding the unnecessary work during delete operations? And I assume you're not Photo entity is not being embedded in collections from other entities via @IndexedEmbedded.

I think you could deal with it using another approach, which has the benefit of avoiding hacking into the error-prone FullTextIndexEventListener:
* look at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessorFactory
* extend it, overriding
and making sure you invoke super.getProcessor but removing from the list all work which is relative to private Photo instances (you might need to index a private/public token to be able to read it from here).

* configure your new backend to replace the default one :



This won't prevent you to do some work about creating the LuceneWork, but at least the engine will be able to figure out the proper events. Also, it's expected that people replace the back end as that's a proper extension point.

there's an open issue to properly support this: http://opensource.atlassian.com/project ... SEARCH-471
if you want you could contribute a patch

Hi Sanne

Many thanks for your help on this. It works perfectly and as you mention, without doing extra work adding/deleting entities from index unnecessarily. I post the code below, perhaps it might be of help to someone else.

I attach two versions of the overridden function you suggest, the first one works perfectly and the second one raises an exception.

Code that works:


Code that removes a 'work' from the queue and raises the exception below:


Exception:



Is that the right approach or I'm missing something?

Thanks mil,

Jordi

the first one is correct, you need a defensive copy on the list: you can't change a list you are iterating or you'll get an exception - this is just basic Java rules.

The stacktrace you have shown should have a "caused by" in the logs as well pointing to the exception in your code.

We've done some testing and works fine with all operations (insert/delete/update).

Thanks much Sanne for showing us the way to go with this. We were stuck with our old code.

Jordi