Hi, here comes a follow up on my previous email regarding configuration of dynamic sharding. Now I would like to get some feedback on ShardIdentifierProvider. This interface was added for dynamic sharding on top of DynamicShardingStrategy. Gunnar and I had a discussion around it today [1] and we came to the conclusion that this interface is actually not needed and just adds confusion in the API. Really ShardIdentifierProvider is a IndexShardingStrategy in disguise. Add 'forAddtion' and 'forDeletion' to the two 'getShardIdentifier' methods and you have (almost) an IndexShardingStrategy. The problem seems to be, that in order to implement dynamic sharding the IndexManagerHolder and EntityIndexBinding are needed. IndexShardingStrategy#initialize does not provide access to these objects which maybe led to the current design. In DynamicShardingStrategy this is taken care of by passing IndexManagerHolder and EntityIndexBinding as part of the constructor arguments. Otherwise DynamicShardingStrategy is just a very thin wrapper delegating to the ShardIdentifierProvider. If the current IndexShardingStrategy#initialize method would get passed the required information for dynamic sharding, there would be no need for an additional interface like ShardIdentifierProvider. Dynamic sharding could be implemented with the existing extension points and implementations would fit better into the current pattern of providing custom implementations. What we could do is to make DynamicShardingStrategy an interface extending IndexShardingStrategy and adding a second initialise contract of sorts. This would keep backwards compatibility, but also allow for dynamic sharding by users implementing DynamicShardingStrategy. At the downside the user would have to write a bit more code, but I think that's acceptable given the more consistent approach towards sharding. Thoughts? --Hardy P.S. In case you guys think that we really should hold on to ShardIdentifierProvider, I would at least suggest to either rename the two 'getShardIdentifier' methods adding 'forAddition' and 'forDeletion' or even collapse the two into a single method (not sure whether this is easily possible) [1] http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 2 Jan 2013, at 3:06 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > Turning the problem upside down, I wonder if IndexShardingStrategy > should be deprecated and have SharIdentifierProvider as the API a user > would implement. It makes for simpler things. What would we lose feature > wise? That is exactly what we have done and we don't think anything is lost :-)