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 <ha...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
