> >
> > AFAIK jcr:data is only indexed in the nodeIndex and not as
> a separate
> > property, hence I think jcr:contains(jcr:content/jcr:data, 'fusce')
> > would not work.
>
> >>> /jcr:root/nen:content//element(*,nen:resource)[@dep:isarticle and
> >>> @dep:state = 'published' and @nen:type = '1' and
> >>> jcr:contains(jcr:content/@jcr:data,
> >>> 'fusce')]
>
>
> The thing is, the last one did work with a previous version
> of jackrabbit. I'm now on jr 1.4. I might try upgrading to
> the latest to see if it fixes it..
Well, just because it shouldn't work like you describe, that if it
worked before, I doubt whether it worked correctly (or just by
coincidence): It might be that < 1.4 a query like jcr:content/@jcr:data
would result in the same query as jcr:content/. (so, < 1.4 you might
query for jcr:content/@jcr:data and find hits, but probably, also when
the hit was just in, say, the title property instead of jcr:data : you
cannot specifically query in *only* jcr:data of a node, at least, AFAIU)
The point is, and you can simply see this in the NodeIndexer, that
jcr:data is not indexed seperately as a Field in lucene, but gathered in
the FULL_TEXT lucene field, together with other nodeScopeIndexed
properties (by default all, see [1])
-Ard
[1] http://wiki.apache.org/jackrabbit/IndexingConfiguration
>
> --
> Torgeir Veimo
> torgeir@pobox.com
>
>
>
>
>
|