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

[Sanne Grinovero]

2011/1/14 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 14 janv. 2011, at 13:47, Hardy Ferentschik wrote:
>
>> On Fri, 14 Jan 2011 11:33:25 +0100, Sanne Grinovero
>> <sanne.grinovero at gmail.com> wrote:
>>
>>> Agreed, also there where additional similar requests recently via the
>>> forums. As usual, alternatives where found but we should make this
>>> easier.
>>
>>> * 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?

Could be useful for emergency situations, like filesystem needs to be
set in readonly mode and people don't care for index sync temporarily.
I'm fine to skip/postpone this, people have been asking for it but
AFAIR always to workaround some other crazy scenario.

>>> * FullTextSession.enableIndexing(boolean)
>>> toggles indexing for the currently open session
>>
>> I don't find this very useful. Could be skipped imo
>
> What's the use case behind it?

This approach is the most close to what users have been asking for,
just disabling it with a single method call.
Is not as polished and consistent as the next two, but I still see
this ease of use compelling.

>>> * entity controlled, via an entity-level annotation pointing to some
>>> custom implementation respecting interface:
>>> boolean indexingEnabled(T entity)
>>> This one is more tricky, should we evaluate it twice (before and after
>>> changes) to see if an index delete operation should trigger?
>>> As an alternative, could it have sense to provide a more complex
>>> interface which controls add/update/delete triggers prevention.
>>
>> That would really be the solution for the HSEARCH-471 usecase, hence +1
>> Of course we would have to settle the details.
>
> It seems to me in the use cases we have seen so far was to minimize the numbers of indexing as an optimization. In this case, delete operations should always be applied. It's just Update that is impacted (maybe insert).

First, it depends if you want to minimize the documents in the index,
or if you want to minimize changes to the index (including deletions).
Second, people have been asking to "hide" some information for
security reasons; they have been suggested to use a filter, but nobody
is ever going to look at all those documents: a waste of space; for
this security requirement we can't avoid or postpone delete
operations.

>>> * 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;
>  }
> }

exactly! simple and reusable by the mass indexer.

Am I missing other approaches? we've been collecting quite some
feedback on these.

Sanne

>
>>
>> --Hardy