jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: sql extension
Date Thu, 17 Mar 2005 08:40:10 GMT
Hi Edgar,

Edgar Poce wrote:
>  I'd like to add some features to the search engine. But rather than
> hacking the jackrabbit search engine I'm thinking of
> making a library that run on top of the jcr api.

this certainly has the advantage that you could use those extensions on 
any jcr implementation. I'm not sure if it is possible to add the 
extensions you have in mind just on top of a jcr implementation. If 
those extension simply filter, re-order or modify the query result, then 
it is possible.

> The sequence would be:
> 1. parse a query with extended language and functionality.
> 2. transform the extended query in a jcr compliant one
> 3. run the jcr query in the jcr implementation
> 4. run the necessary operations to return the extended query result.
> Initially I'd like to add support for arithmetic and string expressions
> in the select clause with a pluggable mechanism for adding functions.

I'd be very interested to see such a support. The main design goal with 
the current implementation was interoperability with XPath and SQL. The 
mandatory parts of both syntaxes share the same implementation to 
actually perfom the query. On occasion I was also thinking about better 
separating the query languages and allow extension. at the moment the 
query implementation can only be replaced as a whole, and does not have 
any other extension points, even though I'd like to change that. the 
problem is a bit that when you go down one layer, it becomes already 
implementation specific (what kind of index is used, etc.). so defining 
an interface or pluggable functions requires abstraction of the 
underlying index to be independent from the actual implementation or the 
interface becomes implementation specific and cannot be reused with 
another query implementation. I didn't find a convincing approach yet. 
but maybe we should just be pragmatic and define extension points for 
the one implementation jackrabbit currently has.

sorry, that was maybe a bit excessive and did not hit your exact 
question, but i thought it is a good occasion to share some thoughts 
about the query implementation.

> I would also like to add a GROUP BY clause, and a HAVING clause.
> Both supporting the extended expression language. But I'm not sure how
> to extend the WHERE clause without a serious drawback on performance.

Yes, I can see what you mean.

Just one more thought on the two query syntaxes. I personally think that 
jackrabbit should focus on XPath because of the hierarchical structure 
of jcr. Using SQL to query a jcr works fine and is easy to use, as long 
as no complex path restrictions are required. But it gets pretty 
complicated when you want to express a XPath query with predicates at 
different location steps in SQL.
But I also see that SQL defines some very useful features XPath is 
missing, and and that it makes sense to implement such features even 
though they cannot be used from XPath. Maybe XQuery is the solution, but 
that's another story.


View raw message