[hibernate-dev] [Search] Dynamic sharding configuration

[Sanne Grinovero]

Guys let's put this into perspective.
These arguments I'm hearing against adding a method in a power-user
oriented SPI are way outbalancing the harm they do to the project in
terms of release delays and our very own time, there are definitely
more interesting issues to dedicate our time on.

I appreciate the tech discussions, but ultimately here we're talking
about an experimental interface which most users won't care about.
Some other users will have very specific high end requirements, and
those are our target: I don't appreciate how we spend more than 30
minutes arguing how these smart guys might get confused by a method
name.
We're not changing the Session contract or anything big like that,
we're providing a damn useful feature but really the method name or
signature is not so relevant, but it's important that we address the
right problem:
 - sane (no null parameters)
 - fulfill the requirements of flexibilty that we expect from a user
extension point (be able to return a Set)
 - make sure it's not a performance bottleneck (implementable without
too many object allocations)

Given this, I'd prefer you to merge my PR from branch HSEARCH-1429 as
it fullfills all the requirements.
(that's pull https://github.com/hibernate/hibernate-search/pull/502 )
and move on, unless you have some really good argument against it,
putting the time & features into perspective.

Alternatively for the sake of moving forward, I'll craft a pull which
just adds the @Experimental and some docs warnings, but I think we're
failing to deliver a good feature which is ready to be delivered today
-> very sad.

Sanne