[hibernate-dev] [Search] Sharding configured on types, not on indexes

[Sanne Grinovero]

After more feedback about sharding from IRC and the forum [1], I
believe we should bind sharding implementations to indexed types, as
opposing to index names.
Currently a sharding strategy is strongly related to the index, but
configured on the index name and so it will affect all entities using
that same index name: there's no need to enforce this.

This also means we could change the sharding strategy interface to:
 a - deal with Entity instances instead of org.apache.lucene.Document
and string-encoded ids
 b - be a typesafe interface using generics

This would affect configuration: instead of configuring them on the
index name, an annotation should be placed on the type (or an optional
parameter for existing @Indexed).

So we won't be able to figure out in how many shards an index is
divided at boot time (unless we ask the sharding strategy via a new
method for this purpose), but this is good provided we finally support
dynamic sharding: start IndexManagers on demand as needed.

Configuration should have been reworked anyway, as it currently
supports only numbers as sub-indexes identifiers.

On top of a greater flexibility in sharding, but will also avoid
exposing the o.a.l.Document yet in another API. Not last, I've seen
cases in which people where forced to encode some token in the
Document only for the sake of their sharding strategy decision logic.

Sanne

1 - https://forum.hibernate.org/viewtopic.php?f=9&t=1011836