2013/10/8 Sanne Grinovero <sanne(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev