[hibernate-dev] [Search] Dynamic sharding configuration

[Gunnar Morling]

2013/10/8 Sanne Grinovero <sanne at hibernate.org>

> 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.
>

Yes, the implementation would likely look as you describe. Personally I
think users would be able to deal with an optional property of a parameter
object and act accordingly; I can see your concern, though.

When setting out with getShardIdentifier()/getShardIdentifierForDeletion(),
there might be a proliferation of methods when supporting new types of
input such as the actual entity; we'd then have to add
getShardIdentifierByEntity() and getShardIdentifierByEntityForDeletion()
and so on.

I guess both approaches would work, in the end its not that a huge
difference.

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.
>

Here I'm still missing a piece I guess. So far we spoke about returning
null, the *empty* set or a set with *all* ids. Is there an example where
one would return *some* ids (the logging example returns exactly one id)?
In other words, I can't imagine a case where one would conclude *some*
shard ids from a given entity which IMO would really justify using a set.

If it is only about returning the info "XYZ is the exact shard id" vs.
"can't determine a shard id, so consider all", a defined constant may be
returned in the latter case, signaling that getAllShardIds() is to be
called after that.

Regarding your example of returning the empty set to skip index updates on
deletions, how would that work in a non-sharded environment? Is using the
shard id provider really the right approach for this problem?

--Gunnar

Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>