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]
