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 Fri, 24 Nov 2006 16:46:13 GMT

Not sure I understand what you meant by "extend JCR API" - I guess adding 
new features to JCR2.0?  Or adding new features to Jackrabbit? 

Simply put, it would be good to see added support for SELECT DISTINCT and 
GROUP BY. I haven't tried with Jackrabbit for JOIN between primary 
nodetype tables, it would be nice if it is there.

An example, if one needs to create a content navigator (similar to the 
JTree format) for search results, one way is to grab ALL data and use 
application code to create the navigational structure. Another way is to 
use one query (like SELECT DISTINCT, and/or GROUP BY ) to get the 
navigation data (tree nodes), and user another query (when user selects 
one category) to get the requested details. 

>Is this now not more an implementation issue (how to do it) than a
>user issue (what features are required, how the API looks like)?

No. See below.

>AFAIK, Lucene (not the RDBMS) is used to for queries (except for
>direct, relative Node access and references).

That's what I thought. Just wonder, wouldn't the RDBMS search/index engine 
be faster than an added layer of external code? This is part of the reason 
I feel it may be beneficial to expand the DB schema and not use Blobs - 
let the DB do the indexing and search - if I'm using DB repository.

>For me, the main reasons to use RDBMS are transaction support and speed.
So I have a file system index from Lucene, on top of another DB index for 

>I know, many people think like that. On the other hand, if using Blobs
>is faster, and people don't wants to access the data store directly,
>why not use Blobs?

Agreed. Like I said before, this is more of a "convincing others" issue. 
In business, it could be one of the factors that affect decision making by 
business users. (Aren't we IT people paid by business :-). 


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