jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sam lee <skyn...@gmail.com>
Subject Re: How to avoid sequential scans in queries
Date Fri, 15 Oct 2010 13:26:32 GMT
This might be interesting:
http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/15557/focus=15559

I think jackrabbit will continue to support XPath and you should use XPath
or SQL, not SQL2 or JQOM at the moment.

or you fix it and submit the patch.
relevant ticket: https://issues.apache.org/jira/browse/JCR-2715




On Fri, Oct 15, 2010 at 8:46 AM, hwellmann <harald.wellmann@multi-m.de>wrote:

>
> OK. so XPath and SQL are deprecated but fast, SQL2 is current but slow (and
> has rather clumsy syntax, for my taste,  compared to XPath).
>
> This raises a couple of questions:
>
> 1) On the implementation side: For a "production-ready implementation of
> JCR
> 2.0" (quoted from Jackrabbit homepage), I would expect production-ready
> performance.
>
> Meanwhile I've found similar and more detailed observations from other
> users
> (
> http://jackrabbit.510166.n4.nabble.com/Performance-of-SQL-2-versus-XPATH-td1590422.html
> ).
> I think it's ok for a reference implementation to be functionally correct
> but not optimized, but production-ready is another story...
>
> It would be fair at least to add some words of warning on the relevant wiki
> page (http://wiki.apache.org/jackrabbit/Search).
>
> 2) On the specification side: Why on earth was XPath deprecated? Even when
> the SQL2 implementation gets improved, the syntax remains cumbersome. (I
> realize this is a JCR and not a Jackrabbit question....)
>
> 3) Is it safe to implement a new application with Jackrabbit 2.x and XPath
> query syntax? Will Jackrabbit continue to support XPath in all 2.x
> releases?
>
> Best regards,
> Harald
>
>
>
> --
> View this message in context:
> http://jackrabbit.510166.n4.nabble.com/How-to-avoid-sequential-scans-in-queries-tp2996800p2996958.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>

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