Sanne,
As you say adding yet another interface makes things even more difficult to
grok; So I'd vote for adding the method for the deletion use case to SIP
directly.
I'm not sure whether it has been considered before, but maybe we could
unify the methods and work with a parameter object as a middle ground:
public interface ShardIdentifierProvider {
void initialize(Properties properties, BuildContext buildContext);
Set<String>
getShardIdentifiersForEntity(EntityShardIdentifierRetrievalContext
retrievalContext);
Set<String>
getShardIdentifiersForQuery(QueryShardIdentifierRetrievalContext
retrievalContext);
Set<String> getAllShardIdentifiers();
}
EntityShardIdentifierRetrievalContext would provide all parameters usable
for shard determination, clearly stating that "document" is not available
in cases such as deleting. Such a parameter object would allow for adding
more options in the future in a compatible manner, and also the method
names read quite nicely and symmetrically (I share Hardy's concerns about
the asymmetry of getShardIdentifier() vs. getShardIdentifiersForDeletion()).
The disadvantage of this scheme is that a set needs to be returned also for
the case of returning a single identifier during insert/update, which might
render the approach not feasible. OTOH I'm wondering why a set needs to be
returned for the delete case, your example also returns exactly one
identifier?
--Gunnar
2013/10/8 Sanne Grinovero <sa...@hibernate.org>
> I've included an example which represents a good reason to provide the
> controversial method.
> Technically the test is crafted as a static sharding approach but is
> using the new API; you can easily figure the same case for a dynamic
> sharding case; also considering we're deprecating the older static
> sharding API, this should also be able to replace whatever was
> possible before.
>
> Could you have a look, reject one and review/merge the other:
> - https://github.com/hibernate/hibernate-search/pull/501
> - https://github.com/hibernate/hibernate-search/pull/502
>
> I personally have a mild preference for "proposal A", as I think the
> additional interface introduced in "proposal B" doesn't simplify but
> adds an additional mark on the list of things the user needs to learn
> about, but I'm happy with both solutions as long as we move on with
> one.
>
> We'll update documentation in a second PR, depending which way we go :-)
>
> Cheers,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
