We're making some really great progress on the query and search features. I just
committed a change that fully implements and integrates the JCR interfaces related to
querying. Note, however, that the underlying connectors do not yet support queries or
searches, so it's still not yet possible to run queries or searches via JCR.
That's what I'll be working on next.
But I thought you might be interested to hear what the feature will look like to a JCR
client.
Our implementation of javax.jcr.query.QueryManager supports three languages:
JCR-SQL2 that is spelled out in the JCR 2.0 specification, with enhancements to the
grammar to support UNION, INTERSECT, EXCEPT, IN clauses, SELECT DISTINCT, LIMIT (with max
rows and an optional row offset), additional join types, BETWEEN criteria, and the
PATH(...) and DEPTH(...) functions for use on the left-hand side of criteria (e.g.,
dynamic operands).
The XPath language is that specified by JCR 1.0.
And the free-text search language just allows the client to submit a search expression
that complies with the Section 6.7.19 of the JCR 2.0 specification (the same search
grammar used in the JCR-JQOM 'FullTextSearch' criteria and the
'CONTAINS(...)' function in JCR-SQL2). So rather than writing a JCR-SQL2 query
like "SELECT * FROM [nt:base] WHERE CONTAINS([nt:base].*, 'term1 term2
term3')", it's actually possible to just issue a query "term1 term2
term3" using the "Search" language, and using the QueryResults to access
the nodes (just like the other languages).
Our implementation simply delegates down to the Graph API, via new 'query(...)'
and 'search(...)' method. The Graph implementation uses our QueryEngine to do the
planning, validation, optimization, and processing, though right now the connectors only
have to implement what we call "access queries", which are the low-level simple
queries involving a single table. Criteria that can be pushed down will be pushed down,
but the graph query engine will implement any JOINs, UNIONS, INTERSECTs, EXCEPTs, or
application of criteria involving results from multiple access queries. We plan to
improve on this over time to push more and more of the queries down to the connectors,
based upon connector capabilities. Connectors will even be able to embed an instance of
our QueryEngine to get full-blow query planning, validation, optimization, and processing
capabilities.
So, once again, my next step is to embed the SearchEngine implementation (which uses
Lucene as the default provider) into the connectors. At that point, we should have query
and search functionality. We're getting really close!
Best regards,
Randall