Re: [hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider
On 21 April 2016 at 18:35, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
As IndexShardingStrategy is deprecated, I thought I'd use
ShardIdentifierProvider and friends in new code I write. It's not clear to
me though, how it's meant to be used.
Some questions:
* Is it correct that EntityIndexBinding#getShardIdentifierProvider()
returns null is sharding is not used for this entity?
Yes, as the javadoc suggests.
I don't like to return "null"s so if
I suppose in that
case I simply can use EntityIndexBinding.getIndexManagers()[0]?
I'm not understanding how this related to the previous question. What
are you up to?
N.B. the intent of the sharding strategies is not to give end users a
reference to the IndexManagers.
So the `ShardIdentifierProvider` contract lets people identify the
target indexes by naming them.
* What's the envisioned way to get the IM for a given shard once
I know the
shard id? I found IndexManagerHolder.getOrCreateIndexManager(), but this
expects a *DynamicSharding*EntityIndexBinding, so how would it work for
non-dynamic sharding?
The envisioned way is that the user doesn't get a reference to the IndexManager,
what he needs is to identify the indexes - not act on them.
It's tough to see how the pieces are meant to fit together, now that
IndexShardingStrategy and ShardIdentifierProvider are there. I hope we can
get rid of the former soon, simplifying the code a bit?
Yes. It has been deprecated for long enough, we could give a shot of
removing the old one if this helps something you're doing?
I wouldn't remove it yet if it's not in the way of our 5.6 requirements.
BTW the contract "IndexShardingStrategy" is deprecated so that users
of sharding move to the new API, but that interface still is the
foundation of the implementation even for dynamic sharding.. it's not
being removed from internals.
The new contract just enables us to add new shards dynamically, but
you can see this also as a removal of the previous limitation. The
high level concept can keep the generic name "index sharding strategy"
as it's still fitting.
You can see this as a plan to not have users to choose between two
ways to express the same thing.
Thanks,
Sanne
Thanks,
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev