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: Restricting xpath query to document text
Date Thu, 11 May 2006 19:02:53 GMT
thomasg wrote:
> Yep I've just found the part in the jcr spec that says jcr:like only
> supported for string properties. Do you have any idea how easy / difficult
> it would be for us to change this behaviour for our application? It looks
> like we need to enable wildcard search in the document text. I guess we
> could duplicate the doc text in a string property but would probably be
> better for us to modify the jcr:like behaviour.

you can try the following:

1) write your own query handler that extends from 
o.a.j.c.query.lucene.SearchIndex and overwrite the method createDocument()
2) write your own NodeIndexer extending from 
o.a.j.c.query.lucene.NodeIndexer which is then used in the above 
mentioned method.
3) from here on it gets a bit nasty!! in your custom NodeIndexer 
overwrite the method addBinaryValue(). you probably have to copy the 
method and adapt it. after obtaining the  map of fields returned by 
the text filter look for the Reader that was returned with the key 
FieldNames.FULLTEXT. you then have to spool the reader into a string 
value and call addStringValue().

This way the jcr:data property is fulltext indexed twice, once in the 
node scoped fulltext index (the one you can use with 
jcr:contains(.,'whatever') ) and again in the field fulltext index, 
which allows you to use jcr:contains(@jcr:data,'whatever'). In 
addition the value is put a third time to the index as a whole 
(untokenized) which allows you to use jcr:like(@jcr:date, '%foo%')

this adds some overhead to the indexing process of nt:resource nodes, 
so be sure you really need it and are willing to pay the price...


View raw message