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.