[hibernate-dev] [Search] Dynamic sharding configuration

[Hardy Ferentschik]

On 8 Jan 2013, at 11:56 AM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Having said that, let's try to find the best proposal possible by
> lunch time, as one of the approaches needs to be merged: 

I think we very well could go w/ the current state right now and evolve in future versions.
I would like to explore Gunnar's idea for example. And of course the whole idea of 
determining the shard id when the document is build.

Given that the old approach is just deprecated nothing is lost for the user yet. 
We would just be more conservative on what we offer right now.

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

What would be terrible about it? In fact if we do the shard id determination earlier 
you might in some cases even have an entity in the deletion case.

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

We just have to disagree on this one. I find the API as proposed confusing.
Simple string returns via sets and confusing names. I would rather have a 
context object with a cleat semantic.

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

What is the difference to what you are proposing?

String getShardIdentifier(Class<?> entityType, Serializable id, String idAsString, Document document);
Set<String> getShardIdentifier(Class<?> entityType, Serializable id, String idAsString);

So you are saying one can determine the use of each of the method just by its contract?

> defining a contract of two different contexts - even maybe
> just overloading the same method - is a much clearer set of
> instructions to the implementor.

Not always.

--Hardy