[hibernate-dev] [Search] Dynamic sharding configuration

[Sanne Grinovero]

We'll need to time cap this discussion as we're way too late, of
course this will need to be tagged @experimental.
Having said that, let's try to find the best proposal possible by
lunch time, as one of the approaches needs to be merged: it's very
clear that there is big practical value for the user to narrow down
deletions.

The parameter object approach got my interest but I'll need an
example, including the user code implementing the methods, as I
suspect a terrible result.

I'm pretty sure I would implement this API with small and short
methods. As an implementor of such an interface, the first thing I
would do is to figure if I'm in the delete case or not - since it's
special - and branch off between two methods, after writing the
condition check. So I already have 3 methods, and a condition which I
could copy paste from the book.
End result, I still have to implement the two methods I'm proposing
(in addition!), but first I need to understand that "some parameters
might be missing" at runtime. That's an absolutely bad idea: using
null as a canary token in a method is awful, especially if it's our
code calling into user code.

The method has to be a clear contract even without reading the
javadoc, providing such an explanation in English prose is by far not
as clear; defining a contract of two different contexts - even maybe
just overloading the same method - is a much clearer set of
instructions to the implementor.

On 8 October 2013 10:03, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> See the comments I made on the pull requests. I also don't think the deletion case should return a set. Either one knows the shard it and returns it or one does not know and you have
> to return null. In the latter case it is up to us to apply the default strategy. IMO it is wrong to say to the user "if you don't know just return all shard ids". It takes away the option from us
> to distinguish between these two cases.
>

In the mail I've sent yesterday I've described an interesting use case
to return an empty set for nightly index rebuilds. That should
highlight that depending on the scenario there is a full range of
options, from the empty set to the universe set. We're clearly talking
about sets.
BTW It was your proposal initially to use Set, that was a very good
one. I don't see the need for us to "distinguish between these two
cases", for one because there are more than two cases, but especially
as we have no use of making this distinction.

Sanne