[hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider

[Sanne Grinovero]

On 21 April 2016 at 18:35, Gunnar Morling <gunnar at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev