Hi Philip, Thanks for your feedback.
> I have been experiencing performance issues with my application. These > problems > have caused me to reflect on how my application is using JCR vs. the custom > object model > that it was using before. Based upon my thoughts, I think that I will have > to migrate away > from JCR, back to a custom schema. I think it is important to understand that performance issues are implementation issues (in the vast majority of the cases) and not specification issues. > Much of my application consists of 1) Search 2) display search results 3) > view search result. > If I perform a search, and I get a hit on a PDF document, > I do not need to load the pdf byte array (jcr:data) into the node in order to > display > my search results. I agree. What makes you think that thats what happens? The spec certainly allows for "lazy loading" of property values and jackrabbit (mostly) makes use of that for binary properties. Sometimes a slow implementation of a Value.getLength() [which is used on typical typical results pages, displaying a filesize] may trigger the loading of the binary property. But again this is an implementation (JR) issue, not a spec issue. I think it is save to say that since your use case is a very typical one for a content repository, it should be blazingly fast in JR. > That is the crux of my performance issue. When I get 400 search results > in a JCR search, I need to only display the only the first 10, and only > utilize > a few of the properties. I don't need to load all the properties for all 400 > nodes. I should note that while there is a next/skip on the NodeIterator, I > need to evaluate a least some of the properties for each of the 400 nodes > since some of the Nodes are duplicate results based upon tagging... >From a JCR perspective it is important to know that you can specify the properties that you are interested in your query. for example ... SELECT jcr:lastModified, jcr:path FROM nt:resource WHERE CONTAINS(*, 'jsr 170') or equivalent in xpath ... //element(*, nt:resource)[jcr:contains(., 'jsr 170')]/(@jcr:lastModified|@jcr:path) ... so you will not have to fetch the nodes, but can have direct access to the property values through .getRows() on the QueryResult. > So summarize my thought in a different way, if the JCR spec could > be amended to support the dynamic selection of Node properties to > be initialized in a NodeIterator, this would provide my application the > flexibility to perform as required. For queries that should already already taken care of (see above). Please keep in mind that the specification leaves it up to the implementation when to load the property values. As mentioned: I think your use case is very typical for a content repository and I am convinced that we can help you to get to the performance you need for your application either through configuration or performance optimizations in the jackrabbit implementation. regards, david
