That's what I was aiming for although from the description it's still unclear to me if: 1. the new method really leads to fewer database accesses (one would expect so) 2. it is used by QueryIterator without extra work for the API user 3. it's possible to construct the path array with a Row from a query without DB roundtrips
But I might just try that out, thanks for the hint ! Regards, Kevin -----Ursprüngliche Nachricht----- Von: Lukas Kahwe Smith [mailto:[email protected]] Gesendet: Montag, 16. Januar 2012 13:51 An: [email protected] Betreff: Re: Bulk load of several nodes On Jan 16, 2012, at 13:46 , Kevin Müller wrote: > Thanks for your answer Alex. > > "No, there will be one query. This acts against the lucene search index. > For each result (= row = node) based on the search index, the node be > loaded (= fetched from the persistence manager). > That last step can be done lazily - i.e. only a number X of results is > fetched at the beginning, the rest will be fetched when you iterate that > far through the results (see resultFetchSize [0])." > > The second step is what I was talking about, not the Lucene query but the SQL > query that fetches the actual data for each node (I'm using a > DatabasePersistenceManager). One separate query is executed for each result > node. > > "Now for the nodes itself: if you use a bundle persistence manager, nodes > are stored as "node bundle" which consist of all properties (except for > larger binaries in the data store). Thus if a node is fetched from the > persistence manager, it will already have all properties in-memory." > > Yes, that means I can get all properties of ONE node in ONE database query > but I still can't get properties of N nodes in ONE query. If we communicate > with a non local database and we get like 100 search results this could be > quite a speedup I imagine ... checkout http://java.net/jira/browse/JSR_333-38 the necessary changes have already been applied in Jackrabbit 2.3.x regards, Lukas Kahwe Smith [email protected]
