jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Rhodes <spamsu...@rhoderunner.com>
Subject JCR Drawback Thoughts
Date Fri, 27 Jul 2007 23:45:49 GMT
Hi everyone,

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.

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.  

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...

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.

The custom object model that I referred to beforehand works for me because the objects representing
the content(html,images,pdf's,etc) are separated from the actual content (the html text, the
image file, the pdf).  That is, my HtmlObject, ImageObject pojo's do not contain the byte
content for what they represent, but the binary content for each of this objects is available
via an API call.

Thanks for listening!  I love the jackrabbit community and wish it continued success.


View raw message