jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mreut...@apache.org
Subject svn commit: r161855 - in incubator/jackrabbit/trunk/xdocs/arch/operate: index.xml query.xml
Date Tue, 19 Apr 2005 08:21:01 GMT
Author: mreutegg
Date: Tue Apr 19 01:21:00 2005
New Revision: 161855

URL: http://svn.apache.org/viewcvs?view=rev&rev=161855
Log:
JCR-1: Implementation Architecture Documentation
Added short description of the query implementation.

Added:
    incubator/jackrabbit/trunk/xdocs/arch/operate/query.xml   (with props)
Modified:
    incubator/jackrabbit/trunk/xdocs/arch/operate/index.xml

Modified: incubator/jackrabbit/trunk/xdocs/arch/operate/index.xml
URL: http://svn.apache.org/viewcvs/incubator/jackrabbit/trunk/xdocs/arch/operate/index.xml?view=diff&r1=161854&r2=161855
==============================================================================
--- incubator/jackrabbit/trunk/xdocs/arch/operate/index.xml (original)
+++ incubator/jackrabbit/trunk/xdocs/arch/operate/index.xml Tue Apr 19 01:21:00 2005
@@ -26,8 +26,12 @@
 operates, segmented into a number of common operations.
 </p>
 <p>
-<a href="startup.html">Start-up, Initialize and Configration</a><br />
+<a href="startup.html">Start-up, Initialize and Configration</a><br/>
 What happens on start-up? What can be configured? <a href="startup.html">more...</a>
+</p>
+<p>
+<a href="query.html">QueryManager implementation</a><br/>
+How is query support implemented in Jackrabbit? <a href="query.html">more...</a>
 </p>
 </section>
 </body>

Added: incubator/jackrabbit/trunk/xdocs/arch/operate/query.xml
URL: http://svn.apache.org/viewcvs/incubator/jackrabbit/trunk/xdocs/arch/operate/query.xml?view=auto&rev=161855
==============================================================================
--- incubator/jackrabbit/trunk/xdocs/arch/operate/query.xml (added)
+++ incubator/jackrabbit/trunk/xdocs/arch/operate/query.xml Tue Apr 19 01:21:00 2005
@@ -0,0 +1,134 @@
+<?xml version="1.0"?>
+<!--
+   Copyright 2004-2005 The Apache Software Foundation or its licensors,
+                       as applicable.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+  -->
+<document>
+ <properties>
+  <title>Query implementation</title>
+ </properties>
+ <body>
+<section name="Overview">
+<p>
+Jackrabbit implements both the mandatory XPath and optional SQL 
+query syntax. Its design follows the goal of the JSR-170 specification
+that all the mandatory query features can be expressed either in
+XPath or in SQL. Thus, the actual implementation of the query engine
+is independent of the query syntax used, though Jackrabbit's query
+internals are closer to XPath than SQL, because of the hierarchical
+structure of a JCR.
+</p>
+<p>
+The major parts of the query implementation are:
+<ul>
+<li>XPath Parser</li>
+<li>SQL Parser</li>
+<li>Abstract Query Tree</li>
+<li>Query engine</li>
+<li>Utilities</li>
+</ul>
+</p>
+</section>
+
+<section name="XPath Parser">
+<p>
+The XPath query parser is based on the W3C XQuery grammar definition which
+is not yet final but can be downloaded as draft
+<a href="http://www.w3.org/2005/02/applets/xgrammar.zip">here</a>.
+The reason why Jackrabbit uses the XQuery grammar, rather than the XPath
+grammer, is, that JSR-170 specifies an 'order by' clause for the XPath
+query syntax. This 'order by' clause is borrowed from the
+<a href="http://www.w3.org/TR/xquery/#id-flwor-expressions">XQuery FLWOR</a>
+expression syntax. Befor parsing the XPath query in Jackrabbit, the statement
+is surrounded with dummy code, to form a valid XQuery FLWOR expression and
+is then passed to the XQuery parser.
+</p>
+<p>
+The actual parser is a class generated by JavaCC, which uses the grammar
+that can be found in <code>src/grammar/xpath</code>.
+</p>
+<p>
+The parsed XPath statement is then translated into an Abstract Query Tree.
+See class:
+<code>org.apache.jackrabbit.core.query.xpath.XPathQueryBuilder</code>
+</p>
+</section>
+
+<section name="SQL Parser">
+<p>
+The SQL query parser is generated from a grammar definition located in
+<code>src/grammar/sql</code>. After parsing, the Abstract Syntax Tree
+is translated into the Jackrabbit internal Abstract Query Tree.
+See class:
+<code>org.apache.jackrabbit.core.query.sql.JCRSQLQueryBuilder</code>
+</p>
+</section>
+
+<section name="Abstract Query Tree">
+<p>
+The Abstract Query Tree (AQT) is the common query description format that
+allows Jackrabbit to implement a query engine which is (to a certain
+extent) independent of the query syntax used (XPath or SQL).
+The AQT consists of the classes that are derived from:
+<code>org.apache.jackrabbit.core.query.QueryNode</code>
+</p>
+</section>
+
+<section name="Query Engine">
+<p>
+Now this is where the meat is. The actual implementation of the query engine
+is configurable. One needs to implement the interface:
+<code>org.apache.jackrabbit.core.query.QueryHandler</code>. Jackrabbit comes
+with an implementation that uses a <a href="http://lucene.apache.org/">Lucene</a>
+index: <code>org.apache.jackrabbit.core.query.lucene.SearchIndex</code> This
+index is independent of the persistence manager in use. However
+it is also possible to write a <code>QueryHandler</code> implementation which
is
+aware of the underlying storage (e.g. a database) and executes the query on
+the 'native' storage.
+</p>
+<p>
+The class <code>org.apache.core.query.lucene.LuceneQueryBuilder</code> translates
+the Abstract Query Tree into a query that can be executed against the Lucene
+index. Jackrabbit implements a couple of extensions to the standard Lucene
+classes, primarily to improve performance in an environment with incremental
+indexing like Jackrabbit. Instead of a single index, Jackrabbit uses generations
+of indexes to circumvent costly IndexReader / IndexWriter creation. See:
+<code>org.apache.jackrabbit.core.query.lucene.MultiIndex</code>. The most
+recent generation of the search index is held completely in memory. See:
+<code>org.apache.jackrabbit.core.query.lucene.VolatileIndex</code>. It is
+comparable with the garbage collection in Java, where generations are used to
+move living objects from the young into the old generation over time. Queries
+are then executed on a MultiReader that spans all the indexes. Every now and
+then (depending on the configuration parameters in workspace.xml) indexes
+are merged and nodes marked as deleted in the index are removed. This happens
+similar to how Lucene merges its internal segments.
+</p>
+</section>
+
+<section name="Utilities">
+<p>
+The class <code>org.apache.jackrabbit.core.query.QueryParser</code> allows you
+to translate a query statement into an Abstract Query Tree and vice versa. It's
+a nice tool to see how a query in XPath looks like in SQL or the other way round.
+</p>
+<p>
+The class <code>org.apache.jackrabbit.core.query.PropertyTypeRegistry</code>
+provides fast access to the type information based on property names. The
+Jackrabbit QueryHandler implementation uses this class to coerce value literals
+into other value types.
+</p>
+</section>
+</body>
+</document>

Propchange: incubator/jackrabbit/trunk/xdocs/arch/operate/query.xml
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message