[hibernate-dev] [Search] Dynamic Sharding the second
Hardy Ferentschik
hardy at hibernate.org
Fri Sep 20 11:30:22 EDT 2013
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
More information about the hibernate-dev
mailing list