[hibernate-dev] HSEARCH-471 Ability to selectively index an entity based on its state

From: "lantz moore (JIRA)" <noreply(a)atlassian.com&gt; Date: 14 janvier 2011 01:52:05 HNEC To: emmanuel(a)hibernate.org Subject: [Hibernate-JIRA] Commented: (HSEARCH-471) Ability to selectively index an entity based on its state

Issue (View Online) Key: HSEARCH-471 Issue Type: New Feature Status: Open Priority: Minor Assignee: Unassigned Reporter: Dobes Vandermeer Operations View all View comments View history Ability to selectively index an entity based on its state Updated: 13/Jan/11 6:51 PM Created: 16/Mar/10 12:10 PM The following comment has been added to this issue: [ Permalink ] Author: lantz moore Date: 13/Jan/11 6:51 PM Comment: up until some recent restructuring of FullTextIndexEventListener and EventSourceTransactionContext i was able to implement something like this very easily. first, my use case: we have a few objects that are expensive to index but are modified "a lot". we only want them indexed at a few well defined transitions: initial creation and when certain members are modified. otherwise, we don't need them to be reindexed. to solve this issue with earlier versions of hib-search, we extended FullTextIndexEventListener and overrode processWork. we map classes to MVEL expressions and use the MVEL expressions to evaluate whether or not to index the entity. we define the FullTextIndexEventListener in spring and configure it like: <bean id="fullTextIndexer" class="com.example.dao.hibernate.FullTextIndexEventListener"> <property name="entityChecks"> <map> <entry key="com.example.model.RetailTransaction"> <value> if (event is org.hibernate.event.PostUpdateEvent) { return (oldState.suspended != newState.suspended || entity.getTransactionState().name() != "PENDING") } return true; </value> </entry> </map> </property> </bean> then instead of autoregistering the default listeners, we register this new listener with the appropriate events. for our particular use case this helped us out quite a bit. however, it looks as though we aren't going to be able to do this in the near future because of the redesign of EventSourceTransactionContext and FullTextIndexEventListener. EventSourceTransactionContext.getIndexWorkFlushEventListener looks thru the listeners for the FullTextIndexEventListener like so: for (FlushEventListener listener : flushEventListeners) { if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { return (FullTextIndexEventListener) listener; } } which means our subclass of FTIEL isn't be found. plus, it looks as though FTIEL will soon be final. so, i don't know if we've been "abusing" the system here, or what, but this seemed like a fairly straight forward way of implementing conditional indexing and has worked really well for us for quite some time. i'm not suggesting that hib-search make a dependency on MVEL, etc; however, it would be nice if we were able to continue to subclass FullTextIndexEventListener in the way that we have been. Project: Hibernate Search Components: mapping Affects Versions: 3.1.1.GA Fix Versions: 3.4.0 Description In our system we have entities that are searched but not all of them are available for search - some of them are flagged as "removed". It would improve the efficiency of our search subsystem if we could implement a kind of "filter" that blocked these entities from being added to the search index, since we wouldn't have to make that a search term and our indexes would be somewhat smaller. This message was automatically generated by Atlassian JIRA Enterprise Edition, Version: 4.1-519 - Bug/feature request. If you think it was sent incorrectly, contact one of this server's administrators.