[hibernate-dev] [Search] Dynamic sharding configuration

[Emmanuel Bernard]

On Tue 2013-09-24 10:51, Hardy Ferentschik wrote:
> String[] getShardIdentifiers(Class<?> entity, Serializable id, String idInString);
> 
> all together. Here is my reasoning. AFAIU, the method is there for the deletion of
> documents. In this case we don't have the Lucene document nor the entity and we need
> to know in which shard the document to delete is. The assumptions behind this method is
> that somehow given the type and id I am able to provide this shard or a subset of the shards.
> I doubt, however, that this is practically ever possible. In the end most implementations will
> have to just delegate to getAllShardIdentifiers() anyways. Take the language code example or
> any other case where I shard depending on a given property of the entity. In this case I will
> never be able to make any use of #getShardIdentifiers(Class<?> , Serializable , String)
> 
> In fact the same arguments probably apply to getShardIdentifiersForQuery. What is the use case 
> for that really? In which use case can the set of targeted shards be limited based on knowing the
> type of filers we apply? 
> 
> So why not remove #getShardIdentifiers and #getShardIdentifiersForQuery and start of with a much
> simpler interface. We can indeed mark it as experimental and if the need arises (based on a true use case)
> think about optimisations. 
> 
> The more I think about it, the more I like this more minimalistic approach.

When ISStrategy was introduced the idea was that somehow, the
implementor could receive information from the runtime with the right
(set of) shard(s). For example, in a multi-tenant app and I *know*
what shard the currently logged user is allowed to temper with. I will always filter by
that shard even for deletion.