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

[lantz moore (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=39618#action_39618 ] 

lantz moore commented on HSEARCH-471:
-------------------------------------

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.

> Ability to selectively index an entity based on its state
> ---------------------------------------------------------
>
>                 Key: HSEARCH-471
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471
>             Project: Hibernate Search
>          Issue Type: New Feature
>          Components: mapping
>    Affects Versions: 3.1.1.GA
>            Reporter: Dobes Vandermeer
>            Priority: Minor
>             Fix For: 3.4.0
>
>
> 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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira