On 8 Jan 2013, at 11:56 AM, Sanne Grinovero <sanne(a)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