[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (HSEARCH-471) Ability to selectively index an entity based on its state

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471?pag... ] Hardy Ferentschik edited comment on HSEARCH-471 at 9/9/11 3:57 AM: ------------------------------------------------------------------- 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: {code} <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> {code} 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: {code} for (FlushEventListener listener : flushEventListeners) { if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { return (FullTextIndexEventListener) listener; } } {code} 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. was (Author: visionlink): 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira