Is it possible to add selection criteria while invoking mass Index. We have a large no. of entities that are not needed to be indexed.

Hi,
that's not implemented yet, it's tracked as HSEARCH-499.
It was delayed as I need to figure out what kind of criterias / filters people would need; what is your case?
Would a filter be good enough (see here)?

Yes, it will work. We dont currently use filters but we can add them. I was wondering if attaching criteria would be more flexible.

right, I'm wondering too if there are use cases for that, would like to know as that would be more complex.
It would need to be a detached criteria, anyway, as the MassIndexer is actually performing the work in a different thread than the invoker.

I noticed http://in.relation.to/Bloggers/HibernateSearch34Alpha1FacetingQueryEngineRefactoringMorePerformanceTricks#H-UpdateIndexOnlyWhenAnIndexedPropertyChanges, this will be very useful.

For the selective indexing, we have couple of use cases.
Scenario:
Say A is an indexable entity containing another entity B. In its life cycle, A gets cloned (say A') keeping the same link to B. Such A' may get associated to another entity C.
1. We dont want to index A' at the time of creation. We only want to index A' via C, whenever C gets created. Right now, our process of creating A' is very expensive because of unwanted indexing.

2. We would like to skip A' indexing during mass indexing as well (right now we do that old way of mass index using scollable result set)

Proposal:
What if there is a way for application to have a say. Would it make sense to inject a qualifier per Entity and allow it to decide weather or not index need to be recreated. For each entity instance Hibernate search can then ask this qualifier to go ahead index or not.

if you
1 - start transaction
2 - load A
3 - clone A to A'
4 - persist A'
5 - do whatever you need (don't know)
6 - link A' to C
7 - commit transaction

indexing will only happen at [7], at point [4] you are not wasting any time indexing as it's not doing that.

Or is your use case having long time (like a business process) between steps 4 and 6 ?

Yes, you are right. 4-6 will always happen in a separate transaction. In some cases (for some entities) 4-6 may not even happen.

please help me understand, so you want your index to stay inconsistent for a long time, potentially forever? Are there good reasons for that?

well, Its not really inconsistent, at least not in business sense. Here is why:
1. Entity A is important and Need to be in sync with the index all the time.
2. A' which is clone of Entity A, is a snapshot, lives in the same table as entity A and points to same properties. But A' is of no use until it become part of C (another entity) in which case, properties of A' will be indexed as association of C. In other words, A' will never need to be indexed on its own. This may seem unnecessary data duplication, but per business req, A' is captured as a snapshot in time and will remain this way for the rest of lifetime.

One other way to do this is to keep A' in separate table but there is some extra development cost in maintaining this. Both A and A' are part of large hierarchical structure and there are some more reasons that make having two separate tables difficult.

Hope this justifies the use-case.