Hi,

(With "full-text parsing" I understand parsing a full-text expression,
which consists of one or multiple "contains" conditions, into a
FullTextExpression AST. If you have a different understanding, then please
tell me.)

Full-text parsing was originally needed internally (and was not public) in
the query engine, to support the case where no full-text index is
available. But then we improved and moved those classes to the QueryIndex
API (Filter.getFullTextConstraint) to support query-time aggregation. I
think we still want to support query-time aggregation, so we need to keep
it there. I understand we want to use index-time aggregation by default,
the same as Jackrabbit 2.x, but I don't think we want to drop support for
query-time aggregation, at least not yet yet.


As for the "mountain is big" example, the problem seems to be the
query-time aggregation, not the parsing of the expression in the query
engine, and not the use of the FullTextExpression. If you want to get the
term "mountain is big" from the FullTextExpression, use
FullTextExpression.toString() ("Get the string representation of the
condition.").


Regards,
Thomas




On 21/11/14 08:25, "Chetan Mehrotra" <[email protected]> wrote:

>Thanks Davide for the feedback.
>
>Would be helpful to get some more feedback on what should be done
>there. So waiting for more feedback!
>Chetan Mehrotra
>
>
>On Wed, Nov 19, 2014 at 9:11 PM, Davide Giannella <[email protected]>
>wrote:
>> On 19/11/2014 13:23, Chetan Mehrotra wrote:
>>> ...
>>>
>>> So should we disable the Fulltext parsing happening in QueryEngine?
>>>
>> I think we should reproduce and OOTB behaviour as it was in JR2 as
>> customer updating from that will expect the same behaviour.
>>
>> So I would ensure about what that behaviour is and working accordingly.
>> Then if the behaviour is NOT to split the string, I would like to have
>> this option in a configurable way. In this way customers willing to
>> leverage the boost stuff could trigger some configuration.
>>
>> Could it make sense? (I'm not expert in Lucene) :)
>>
>> Cheers
>> Davide
>>
>>

Reply via email to