[hibernate-dev] HSEARCH-638 and other Search fixes.. another RC?

[Hardy Ferentschik]

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