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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
