After further discussion with Thomas it appears that QueryEngine need to provide a different AST for fulltext expressions such that LuceneIndex can access the non tokenized expression. Opened OAK-2301 to track that Chetan Mehrotra
On Mon, Nov 24, 2014 at 4:03 PM, Thomas Mueller <[email protected]> wrote: > Hi, > >>I want to treat following two differently >> >>1. FulltextExpression created out of simple string term passed to a >>single jcr:contains in a query >>2. FulltextExpression by combining multiple jcr:contains >> >>For #1 it would be better to get access to raw string and pass it to >>Lucene analyzer for tokenization. For #2 it would be preferable to get >>the FullTextExpression AST such that it can be mapped to required >>Lucene query > > The AST should have the same information as the raw string, so that you > should be able to easily generate the raw string form the AST. > >>That can be done but then how can I distinguish from a >>FulltextExpression created out of "mountain is big" and >>_jcr:contains("title","mountain is big")_So if fulltext expression can >>provide some hint from what it was constructed from that might help > > Do you mean jcr:contains(@title, 'mountain is big')? The > FullTextExpression AST for this is: > > FullTextAnd( > FullTextTerm(propertyName="title", text="mountain"), > FullTextTerm(propertyName="title", text="is"), > FullTextTerm(propertyName="title", text="big") > ) > > and toString is: > > title:"mountain" title:"is" title:"big" > > Is this the correct representation? > > Regards, > > Thomas > >
