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.
- 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