Jackrabbit 2.0.0 query language choices

[ChadDavis <ch...@gmail.com>]

I'm starting to implement some search functionality in my application.
 I'm confronted with the choice between four supported query
languages:  sql, xpath, jcr-sql2 and jcr-jqom.

I understand how these languages all sit on top of the AQM.  And I
understand what each of them is . . . I'm familiar with xpath and sql
from previous work.  And I've read the specification to understand
what the programmatic jqom is.  In fact, I've implemented some simple
search with it already.

My question is . . . what are some criteria that might guide a
developer to make a choice of one of the four.

1) Performance ?  Is there any difference in performance?

2) Ease of use . . . is there any sense that the ease of use varies among them?

3) Functionality . . . are there any differences in functionality?

4) Other differentiating factors ?  Are there any other reasons to
consider when making a selection from the four?  I would assume
developer familiarity is a obvious one, others?

Re: Jackrabbit 2.0.0 query language choices

[Alexander Klimetschek <ak...@day.com>]

On Thu, Feb 18, 2010 at 14:31, Will Scheidegger <wi...@mac.com> wrote:
> Xpath is a very good choice for searching in tree structures. Things like
>
> /jcr:root/path/to/elements//element(*, elementType)[path/to/subelement/@attribute = 'value']
>
> are not possible with SQL. Don't know about SQL2 or JQOM though...

This should be possible with JQM / JCR-SQL2 due to the flexible joins
on nodes/child nodes, however I am not yet fluent enough in these to
convert that query ;-)

> Does anyone know what the reasons were for deprecating Xpath in JCR 2.0?

Basically JCR 2.0 no longer prescribes a query language, only the
abstract query model. jcr-sql2 is "just" a convenience mapping of that
language. The idea is that general-purpose libraries are built that
map xpath etc. onto the new AQM.

For more details see http://markmail.org/message/wwadh4disbf5iiej and
the rest of that thread.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Jackrabbit 2.0.0 query language choices

[Will Scheidegger <wi...@mac.com>]

On 18.02.2010, at 13:55, Alexander Klimetschek wrote:

> Well, that depends on personal choice. I think that Xpath is a very
> good fit for tree structures (and that's why I think it's sad that it
> became deprecated in JCR 2.0, albeit it will live on in Jackrabbit).

Xpath became deprecated? Missed that. And allow me to say: Why!?
Xpath is a very good choice for searching in tree structures. Things like

/jcr:root/path/to/elements//element(*, elementType)[path/to/subelement/@attribute = 'value']

are not possible with SQL. Don't know about SQL2 or JQOM though... but xpath is very powerful. The only negative thing about it that I can think of is that queries on paths with path segments beginning with a number don't work that easily.

Does anyone know what the reasons were for deprecating Xpath in JCR 2.0?

-will

Re: Jackrabbit 2.0.0 query language choices

[Alexander Klimetschek <ak...@day.com>]

On Wed, Feb 17, 2010 at 23:24, ChadDavis <ch...@gmail.com> wrote:
> 1) Performance ?  Is there any difference in performance?

No, they all use the same lucene index under the hood, ie. they all
get transformed into a lucene index query.

> 2) Ease of use . . . is there any sense that the ease of use varies among them?

Well, that depends on personal choice. I think that Xpath is a very
good fit for tree structures (and that's why I think it's sad that it
became deprecated in JCR 2.0, albeit it will live on in Jackrabbit).

> 3) Functionality . . . are there any differences in functionality?

JCR-SQL2 / JCR-JQOM in JCR 2.0 most notably support joins, which is
not possible with the older xpath and sql.

> 4) Other differentiating factors ?  Are there any other reasons to
> consider when making a selection from the four?  I would assume
> developer familiarity is a obvious one, others?

I think 2) and 3) are the ones that should drive your decision.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com