jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lei Zhou <L...@pointalliance.com>
Subject Re: Question on jcr:deref usage
Date Thu, 23 Nov 2006 15:33:34 GMT
Thanks Marcel!

So it seems that due to the limitation of JCR (no aggregation query 
support), it would be much slower to support this type of application than 

Is that a correct assessment? 

Also, to articulate, if I have to present to users with a query result 
view that is categorized (or grouped) by ProductName, I'd have to do the 

1. Run query #1
  //element(*, Document)[@Subject = 'Manual' and 

2.  iterate through the entire RowIterator (may have thousands of 
entries),  use Java code
    to create an aggregated ProductNames/ProductReference pairs collection 

    (since JCR doesn't have this type of query),

3. No "Order By" clause is used because the ProductReferences won't be in 
same order as
    the ProductNames, manual sorting is required in Java post-processing

4. Depending on which category has been selected by user to expand, run 
query #2, limiting 
    results to that single product category:
    (query #2)
  //element(*, Document)[@Subject = 'Manual' and 
  'maintenance') and @ProductReference = '<uuid-of-Product-#1>']

5. Again, product names has to be de-referenced manually, and ordering has 
to be moved from
    the query to the java post-processing

I'm fairly new to JCR and Jackrabbit. I've found them very helpful in many 
aspects of managing contents. But I do feel that certains improvements 
could make Jackrabbit a better choice for enterprise use. 

#1. In the many years of enterprise application development, I've seen a 
lot of our content based applications in need of support for complicated 
search, e.g, search by arbitrary combination of document properties, and 
grouping of search results (it is not uncommon to see 2, even 3 levels of 
nested grouping). 
     -- Aggregations and Joins are definitely a big plus for querying a 
complicated content model.

I've seen posts mentioning use of Node references to compensate the lack 
of SQL Join, but what if I need to perform a search like below 
(ProductNames, Regions and AvailableFors would most likely be categories 
that are referenced by all documents): 
    FIND all manuals
    THAT (ProductName is 'TV' or 'VCR' or 'DVD') 
         and (Region is 'North America' or 'Europe') 
         and (AvailableFor is 'distributor' or 'repairHouse')
     GROUP BY Region, ProductName
#2. The RDBMS based repository, current DB schema is not very convincing 
for large enterprise level applications. A more normalized schema might 
help both performance and #1, but yes, more DB level code may be needed 
(for performance's sake) and that may limit the portability of the 

These are just my perspective of evaluating Jackrabbit and I'd welcome any 
comments or corrections on mis-understanding.

All in all, I understand that Jackrabbit is only a reference 
implementation to JCR 1.0, and it is really a great product. Just hoped it 
can be even better and be more extensively adopted just like Apache HTTP 

Best Regards,

Marcel Reutegger <marcel.reutegger@gmx.net> 
11/23/06 09:25 AM
Please respond to


Re: Question on jcr:deref usage

Lei Zhou wrote:
> SELECT  Document.Subject, Document.Description, 
> Document.ProductReference->categoryName
> where Subject='Manual' AND description contains 'maintenance' AND 
> Document.ProductReference->categoryName='Product #1'
> order by Document.ProductReference->categoryName, Document.Subject
> Is this possible in Jackrabbit with Xpath query? 

no, not quite. the jcr:deref() function cannot be used in a predicate, 
would be required for that use case. furthermore the select clause and 
order by 
clause may only contain property names.

the closed you can get is something like:

//element(*, Document)[@Subject = 'Manual' and jcr:contains(@description, 
'maintenance') and @ProductReference = '<uuid-of-Product-#1>'] order by 
@ProductReference, @Subject

and then you have to do some post processing. basically dereferencing the 
ProductReference to get the name of the product.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message