[hibernate-dev] [Search] Dynamic Sharding the second

[Emmanuel Bernard]

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?

Emmanuel

On Fri 2013-09-20 17:30, Hardy Ferentschik wrote:
> 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/2013/%23hibernate-dev.2013-09-20.log.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev