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
