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

[Sanne Grinovero]

2011/1/14 Hardy Ferentschik <hibernate at ferentschik.de>:
> On Fri, 14 Jan 2011 14:24:07 +0100, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>
>>>> * SearchFactory.enableIndexing(boolean) // enables/disables globally on
>>>> the fly
>>>> could operate on existing boolean
>>>> org.hibernate.search.event.FullTextIndexEventListener.used
>>>
>>> +1 This is something I was wishing for some time back. It should be easy
>>> to implement as well. This option should then also be exposed via JMX.
>>
>> What's the use case behind it?
>
> I think it would allow for application which are completely manageable via
> some user interface. At the moment you set the auto indexing option or not.
> If I could programmatically change it I could do things like stop
> auto indexing, do db modifications, purge the index, re-index, enable
> event indexing.
>
>>>> * entity controlled, via an annotated boolean property
>>>> I'd mandate a boolean property, or something which can be easily
>>>> evaluated via a SQL fragment / Criteria / filterable, so that the same
>>>> information could be reused
>>>> by the MassIndexer when picking all values to be indexed.
>>>
>>> Not sure I understand exactly what you mean.
>>
>> @Entity @Indexed
>> public class MyEntity {
>>   ...
>>
>>   @SkipIndexing
>>   boolean isIndexed() {
>>      return status == TEMP;
>>   }
>> }
>
> Wouldn't the other solution be more generic?

yes, but the more flexibility we give, the less clever things we can
do automatically.
Consider the dirty checks we implemented for HSEARCH-361, I had to
disable every optimization
both in case there's a ClassBridge or a BoostStrategy as in those
cases we can't predict
if the index would change.

Similarly, in this case if we allow for a flexible custom made
implementation we should
disable dirty checks on such entities and would have no clue to
provide to the MassIndexer,
at least not without more help from the user;
we'd need to consider at least those cases, something along:

void addRestrictions(Criteria loadingCriteria);

Set<String> getConsideredPropertyNames();

Who knows what else we'll need later.

I'd say @SkipIndexing is more straight-forward, but we can also
support the more flexible approach
as an "advanced" alternative which requires some more coding and care.

Sanne