Maybe it's time to revive this one since we have started to go down the rabbit
hole with indexing only when dirty searched properties are present.
Begin forwarded message:
> From: "lantz moore (JIRA)" <nore...@atlassian.com>
> Date: 14 janvier 2011 01:52:05 HNEC
> To: emman...@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.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
