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...
regards
marcel
