[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471?pag...
]
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira