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