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

[Emmanuel Bernard]

I'm a bit lost. Maybe we could do an IRC session on the subject to get everyone (ahem me) up to speed.

On 11 août 2011, at 13:51, Sanne Grinovero wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev