jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: lucene search separator
Date Wed, 22 Jun 2011 09:53:34 GMT
On 22.06.11 09:05, "Christian Stocker" <christian.stocker@liip.ch> wrote:
>Now we can't tell which are the actual values (we don't want to use
>getNode() for performance reasons, since we use davex and we have to get
>many nodes in one go)

Please note that the JCR search implementation does access the nodes (from
the persistence manager) anyway, to make sure they actually still exist,
and it must run the ACL check, which usually involves a few node reads as
well (to find & read the policies; some caching optimizations are there,

Anyway, there is no way to directly read the lucene index when using the
JCR (search) API.

If you really need to be as fast as possible with that search and the
overhead of the persistence manager & ACL check turns out too much (=
measured), I'd suggest to either build a separate index in the JCR for
your use case (so you do a straight lookup instead of a query), or if the
query is too dynamic, you could use an observation listener and build a
separate index, with a separate lucene index for example (on the
application level).


Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

View raw message