+1 On Dec 8, 2011, at 4:05 PM, Emmanuel Bernard wrote:
> So after discussions but use of the benevolent dictator power, here is what > we will do. > > HSEARCH-638 is a bug (efficiency bug) > > We should drop HSEARCH-800 (see my last comment) > 4.0 can address HSEARCH-795 > 4.1 will address HSEARCH-638, HSEARCH-1003 > > Assuming Core releases Wed night next week we go release *right* in their > foot step and blog about it Thursday 14:00 CET. > > On 8 déc. 2011, at 15:18, Sanne Grinovero wrote: > >> Forgot another issue which would be very "nice to have", just debugged >> on the forums: >> https://hibernate.onjira.com/browse/HSEARCH-1003 TwoWayFieldBridge on >> DocumentId field: no check for single field and correct field name >> >> Sanne >> >> On 8 December 2011 14:14, Sanne Grinovero <sa...@hibernate.org> wrote: >>> I had created a testcase for HSEARCH-638 [1] quite some time ago, and >>> Davide was now so kind to take it over and implement the solution >>> which is almost ready in a pull request. >>> >>> In my opinion, HSEARCH-638 is a performance bug and should be fixed. >>> When we last talked about it, Emmanuel was not considering it being >>> bug, as it was exactly expressing it's original intention.. I believe >>> we settled by saying it would be fine to change the behaviour, BUT he >>> would not consider it a bug fix but an API change as it would affect >>> possible users: indeed that's correct, as it changes what is exactly >>> included in the index, but how I was seeing the index mapping I doubt >>> anybody was relying on it. >>> >>> So now we have a fix, and the project lead considers it an API change. >>> This was the original reason for me when I made the tests for it, to >>> not provide a solution yet, as it would need to wait for 4.0 .. now we >>> have the solution so I think we should rather merge it now than to >>> wait as it might be considered an API change (although I'm not overly >>> convinced of that). >>> >>> Problem is that it's a bit late in the 4.0 train. If you think it's >>> acceptable to make another RC soon, then I'd love to include this and >>> also propose a solution for HSEARCH-598 (MassIndexer freezes when pool >>> size is too low), as I have a POC for it but it's not trivial so I >>> won't send a pull request (nor spend more time on it) unless we'll >>> make another RC. >>> >>> If we could, I'd include two other API changes: >>> - HSEARCH-800 Should we move ORM related APIs to >>> org.hibernate.search.orm? Today they are in org.hibernate.search >>> - HSEARCH-795 Move some of SearchFactoryImplementor from spi to impl >>> (and move SPI level contracts up) >>> >>> should these otherwise be rejected? >>> >>> Sanne >>> >>> 1 - Limit graph traversal by @ContainedIn to the minimum required path >>> - https://hibernate.onjira.com/browse/HSEARCH-638 >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
