Jackrabbit 2.1, JQOM and XPATH

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

I simply need to know which search interface is the most fully
implemented.  I've asked this before, but received no good answer.  I
scoured the mail list archives and discovered that this may be a bit
of a controversial topic; perhaps people are trying not to speak?

It seems that JQOM is not fully implemented, while it seems that XPATH
is.  If you simply read the specification, you would expect to use
JQOM, or SQL2.  But with a lack of functionality in place, and not
much community using the interfaces, I'm not sure I should use them.
I find myself thinking I should use the deprecated XPATH.  Any advice
would be appreciated . . .

As a corallary point . . . I found an old thread saying that all of
the search interfaces will be converted into JQOM under the hood.
However, I can't see that this can be the case, considering that it's
not fully implemented.  Also, the specification says that everything
is converted to AQM under the hood.  Which is the underlying system,
JQOM or AQM.

Thanks for your help, sorry to raise controversial issues, if I am.

Re: Jackrabbit 2.1, JQOM and XPATH

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

> On Fri, Jul 16, 2010 at 19:21, ChadDavis <ch...@gmail.com> wrote:
>> I simply need to know which search interface is the most fully
>> implemented.  I've asked this before, but received no good answer.  I
>> scoured the mail list archives and discovered that this may be a bit
>> of a controversial topic; perhaps people are trying not to speak?
>> 
>> It seems that JQOM is not fully implemented, while it seems that XPATH
>> is.  

Well, XPath or SQL are not "fully implemented" either as a matter of fact: No case-insensitive ordering. Even if that would comply to the specs... then I would say that the specs are not fully specified.
But apparently this should finally work with JQOM I read somewhere. So I guess I'm looking forward to this although I really started to get a hang of XPath. 

Oh well, learn something new every day - otherwise we would get bored now, wouldn't we ;-)

-will

Re: Jackrabbit 2.1, JQOM and XPATH

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

Hi,

On Fri, Jul 16, 2010 at 19:21, ChadDavis <ch...@gmail.com> wrote:
> I simply need to know which search interface is the most fully
> implemented.  I've asked this before, but received no good answer.  I
> scoured the mail list archives and discovered that this may be a bit
> of a controversial topic; perhaps people are trying not to speak?
>
> It seems that JQOM is not fully implemented, while it seems that XPATH
> is.  If you simply read the specification, you would expect to use
> JQOM, or SQL2.  But with a lack of functionality in place, and not
> much community using the interfaces, I'm not sure I should use them.
> I find myself thinking I should use the deprecated XPATH.  Any advice
> would be appreciated . . .

I think most JCR applications out there (still) use XPath and SQL, as
JCR 2.0 is very fresh. That's why Jackrabbit is not going to kill
support for them. And why the XPath and SQL query parsers are stable,
while the fresh JCR-SQL2 / AQM still has a few issues (but it should
support all features, since Jackrabbit 2.0 is TCK compliant, afaik).
Since not so many use it yet, demand to finalize that is (and
patches!) were not so high yet, but it is definitely growing. What
happens in the community depends on what people need and where the
contribute to.

Also many people still argue about the quick deprecation of the "old"
languages. The idea in the 2.0 spec was to have a single fundamental
abstract query model instead of coming up with a specific syntaxes
(note that JCR-SQL2 is "just" a serialization of the AQM for better
examples and ootb usage). The reason for this is because specific
languages come with all their syntactic differences and constraints,
while the spec wanted to standardize the semantics of searching a
hierarchical repository. To push the new AQM idea, the old languages
were deprecated.

For an implementation such as Jackrabbit, the idea would be to build
xpath-to-AQM (and maybe jcrsql1-to-AQM) converters, but the general
need for that was not that high yet.

> As a corallary point . . . I found an old thread saying that all of
> the search interfaces will be converted into JQOM under the hood.
> However, I can't see that this can be the case, considering that it's
> not fully implemented.  Also, the specification says that everything
> is converted to AQM under the hood.  Which is the underlying system,
> JQOM or AQM.

Both are essentially the same (see [1]):
- AQM is the semantical model described in the spec
- JCR-JQOM (or short JQOM) is the Java class representation of that,
see javax.jcr.query.qom.* [2]

JCR-SQL2 is a representation of an AQM in an SQL-like manner.

Just to add to the confusion: The internal implementations of the
"old" Xpath and SQL queries in Jackrabbit also share the same target
java object model for expressing the search, which is called
(abstract) query tree.

In the end, both are evaluated using a Lucene search index. These
actual query-evaluators don't share as much as I first thought, so
this is probably the place were the implementation differences are.
That comes from the quite fundamental change of allowing joins
(multiple selectors) in AQM.

[1] http://www.day.com/specs/jcr/2.0/6_Query.html
[2] http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/query/qom/QueryObjectModelFactory.html

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com