Alexander Klimetschek wrote:
>
> On Thu, Feb 26, 2009 at 10:47 AM, PThiemann
> <[email protected]> wrote:
>> //element(*,
>> custom:file)[jcr:contains(custom:extendedProperties/@XYZ,'F/OS*')]/custom:extendedProperties/rep:excerpt(.)
>>
>> Now there is the strange thing. When I search (leaving out the /) for the
>> following I can see my result again.
>> //element(*, custom:file)[jcr:contains(custom:extendedProperties/@XYZ,'F
>> OS*')]/custom:extendedProperties/rep:excerpt(.)
>>
>> Is the slash not indexed by lucene or do I have to escape the slash for
>> Jackrabbit for not being recognized as path delimiter?
>
> Instead of the "fuzzy" jcr:contains() method, you could use jcr:like()
> which is more accurate if you want to match simple properties - it
> uses "%" as wildcard (just as sql LIKE):
>
> //element(*,custom:file)[jcr:like(custom:extendedProperties/@XYZ,'F/OS%')]/custom:extendedProperties/rep:excerpt(.)
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> [email protected]
>
>
Thank you, that solved my problem getting search hits without any
workaround.
But now I am facing another problem. The excerpt is not highlighted anymore.
I am just getting a excerpt string of all property values of node
'custom:extendedProperties' without any highlighing.
As our customer are currently used to query result highlighting this would
be a real disadvantage.
Does anyone know if query highlighing is supported with jcr:like?
--
View this message in context:
http://www.nabble.com/Slashes-in-wildcard-query-string-do-not-work-tp22220831p22231363.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
