On 22.06.11 09:05, "Christian Stocker" <[email protected]> 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, afaik). 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). Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
