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