jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [jira] Resolved: (JCR-198) jcr:contains doesn't return incomplete match
Date Fri, 26 Aug 2005 13:47:16 GMT
Hi Bertrand,

Bertrand LEGA wrote:
> It goes without saying that I think this is a very usefull feature :)
> 
> Marcel, do you think this is a modification requiring a good expertise 
> of lucene and/or jackrabbit ?

when you know where to look for, it's not that complicated ;)

> If it's a little modification, I may assign somebody from my team to 
> have a look at, or even myself.

those are the changes I think are needed:

- in LuceneQueryBuilder.visit(TextsearchQueryNode node, Object data) we 
need to switch to a different QueryParser that allows wildcards at the 
beginning of a term. The current QueryParser is the one shipped with lucene.
- Adapt the default lucene parser definition and integrate generating 
the new custom parser into the maven build process. You will notice that 
there is a already a comment in the QueryParser.jj file shipped with the 
lucene source distribution that shows how to enable prefix queries.

hmm, I guess that's it already.

> If you feel that this is a sensitive area and that the change should be 
> done by a jackrabbit expert, then, we would wait the implementation 
> (provided the change is accepted).
> 
> What do you think ?

go ahead. any help is appreciated!

> By the way, what is the point to have jcr:like and jcr:contains ? Why 
> not having one operation (and being able to spcify if the query is case 
> sensitive or not) ?

jcr:like was introduced to map the LIKE operator from SQL to XPath. And 
because LIKE is case sensitive in SQL it must behave the same in XPath.

whereas with jcr:contains the aim is to provide a fulltext facility 
which is among other things _not_ case sensitive.

regards
  marcel

Mime
View raw message