jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mdue...@apache.org
Subject svn commit: r1535337 [8/11] - in /jackrabbit/site/live/oak/docs: ./ css/ js/
Date Thu, 24 Oct 2013 10:42:03 GMT
Modified: jackrabbit/site/live/oak/docs/nodestate.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/nodestate.html?rev=1535337&r1=1535336&r2=1535337&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/nodestate.html (original)
+++ jackrabbit/site/live/oak/docs/nodestate.html Thu Oct 24 10:42:02 2013
@@ -1,504 +1,504 @@
-<!DOCTYPE html>
-<!--
- | Generated by Apache Maven Doxia at 2013-10-15
- | Rendered using Apache Maven Fluido Skin 1.3.0
--->
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-  <head>
-    <meta charset="UTF-8" />
-    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20131015" />
-    <meta http-equiv="Content-Language" content="en" />
-    <title>Jackrabbit Oak - </title>
-    <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
-    <link rel="stylesheet" href="./css/site.css" />
-    <link rel="stylesheet" href="./css/print.css" media="print" />
-
-      
-    <script type="text/javascript" src="./js/apache-maven-fluido-1.3.0.min.js"></script>
-
-    
-            </head>
-        <body class="topBarEnabled">
-          
-    
-    
-            
-    
-    
-    <a href="http://github.com/apache/jackrabbit-oak">
-      <img style="position: absolute; top: 0; right: 0; border: 0; z-index: 10000;"
-        src="https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png"
-        alt="Fork me on GitHub">
-    </a>
-  
-                
-                    
-                
-
-    <div id="topbar" class="navbar navbar-fixed-top ">
-      <div class="navbar-inner">
-                <div class="container-fluid">
-        <a data-target=".nav-collapse" data-toggle="collapse" class="btn btn-navbar">
-          <span class="icon-bar"></span>
-          <span class="icon-bar"></span>
-          <span class="icon-bar"></span>
-        </a>
-                
-                                <ul class="nav">
-                          <li class="dropdown">
-        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Overview <b class="caret"></b></a>
-        <ul class="dropdown-menu">
-        
-                      <li>      <a href="index.html"  title="Jackrabbit Oak">Jackrabbit Oak</a>
-</li>
-                  
-                      <li>      <a href="license.html"  title="License">License</a>
-</li>
-                  
-                      <li>      <a href="downloads.html"  title="Downloads">Downloads</a>
-</li>
-                  
-                      <li>      <a href="from_here.html"  title="From here">From here</a>
-</li>
-                          </ul>
-      </li>
-                <li class="dropdown">
-        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Concepts and architecture <b class="caret"></b></a>
-        <ul class="dropdown-menu">
-        
-                      <li>      <a href="overview.html"  title="Overview">Overview</a>
-</li>
-                  
-                      <li>      <a href="nodestate.html"  title="Understanding the node state model">Understanding the node state model</a>
-</li>
-                  
-                      <li>      <a href="microkernel.html"  title="Microkernel">Microkernel</a>
-</li>
-                  
-                      <li>      <a href="query.html"  title="Query">Query</a>
-</li>
-                  
-                      <li>      <a href="blobstore.html"  title="BlobStore">BlobStore</a>
-</li>
-                          </ul>
-      </li>
-                <li class="dropdown">
-        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Using Oak <b class="caret"></b></a>
-        <ul class="dropdown-menu">
-        
-                      <li>      <a href="use_getting_started.html"  title="Getting Started">Getting Started</a>
-</li>
-                  
-                      <li>      <a href="differences.html"  title="Differences to Jackrabbit 2">Differences to Jackrabbit 2</a>
-</li>
-                  
-                      <li>      <a href="dos_and_donts.html"  title="Dos and don'ts">Dos and don'ts</a>
-</li>
-                  
-                      <li>      <a href="when_things_go_wrong.html"  title="When things go wrong">When things go wrong</a>
-</li>
-                          </ul>
-      </li>
-                <li class="dropdown">
-        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developing Oak <b class="caret"></b></a>
-        <ul class="dropdown-menu">
-        
-                      <li>      <a href="dev_getting_started.html"  title="Getting Started">Getting Started</a>
-</li>
-                  
-                      <li>      <a href="participating.html"  title="Participating">Participating</a>
-</li>
-                  
-                      <li>      <a href="apidocs/index.html"  title="API docs">API docs</a>
-</li>
-                          </ul>
-      </li>
-                <li class="dropdown">
-        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Links <b class="caret"></b></a>
-        <ul class="dropdown-menu">
-        
-                      <li>      <a href="http://jackrabbit.apache.org/oak"  title="Apache Jackrabbit Oak">Apache Jackrabbit Oak</a>
-</li>
-                  
-                      <li>      <a href="http://jackrabbit.apache.org/"  title="Apache Jackrabbit">Apache Jackrabbit</a>
-</li>
-                          </ul>
-      </li>
-                  </ul>
-          
-          
-          
-                   
-                      </div>
-          
-        </div>
-      </div>
-    </div>
-    
-        <div class="container-fluid">
-          <div id="banner">
-        <div class="pull-left">
-                                <div id="bannerLeft">
-                <h2>Oak Documentation</h2>
-                </div>
-                      </div>
-        <div class="pull-right">  </div>
-        <div class="clear"><hr/></div>
-      </div>
-
-      <div id="breadcrumbs">
-        <ul class="breadcrumb">
-                
-                    
-                  <li id="publishDate">Last Published: 2013-10-15</li>
-                  <li class="divider">|</li> <li id="projectVersion">Version: 0.11-SNAPSHOT</li>
-                      
-                
-                    
-      
-                            </ul>
-      </div>
-
-            
-      <div class="row-fluid">
-        <div id="leftColumn" class="span3">
-          <div class="well sidebar-nav">
-                
-                    
-                <ul class="nav nav-list">
-                    <li class="nav-header">Overview</li>
-                                
-      <li>
-    
-                          <a href="index.html" title="Jackrabbit Oak">
-          <i class="none"></i>
-        Jackrabbit Oak</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="license.html" title="License">
-          <i class="none"></i>
-        License</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="downloads.html" title="Downloads">
-          <i class="none"></i>
-        Downloads</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="from_here.html" title="From here">
-          <i class="none"></i>
-        From here</a>
-            </li>
-                              <li class="nav-header">Concepts and architecture</li>
-                                
-      <li>
-    
-                          <a href="overview.html" title="Overview">
-          <i class="none"></i>
-        Overview</a>
-            </li>
-                  
-      <li class="active">
-    
-            <a href="#"><i class="none"></i>Understanding the node state model</a>
-          </li>
-                  
-      <li>
-    
-                          <a href="microkernel.html" title="Microkernel">
-          <i class="none"></i>
-        Microkernel</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="query.html" title="Query">
-          <i class="none"></i>
-        Query</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="blobstore.html" title="BlobStore">
-          <i class="none"></i>
-        BlobStore</a>
-            </li>
-                              <li class="nav-header">Using Oak</li>
-                                
-      <li>
-    
-                          <a href="use_getting_started.html" title="Getting Started">
-          <i class="none"></i>
-        Getting Started</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="differences.html" title="Differences to Jackrabbit 2">
-          <i class="none"></i>
-        Differences to Jackrabbit 2</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="dos_and_donts.html" title="Dos and don'ts">
-          <i class="none"></i>
-        Dos and don'ts</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="when_things_go_wrong.html" title="When things go wrong">
-          <i class="none"></i>
-        When things go wrong</a>
-            </li>
-                              <li class="nav-header">Developing Oak</li>
-                                
-      <li>
-    
-                          <a href="dev_getting_started.html" title="Getting Started">
-          <i class="none"></i>
-        Getting Started</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="participating.html" title="Participating">
-          <i class="none"></i>
-        Participating</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="apidocs/index.html" title="API docs">
-          <i class="none"></i>
-        API docs</a>
-            </li>
-                              <li class="nav-header">Links</li>
-                                
-      <li>
-    
-                          <a href="http://jackrabbit.apache.org/oak" class="externalLink" title="Apache Jackrabbit Oak">
-          <i class="none"></i>
-        Apache Jackrabbit Oak</a>
-            </li>
-                  
-      <li>
-    
-                          <a href="http://jackrabbit.apache.org/" class="externalLink" title="Apache Jackrabbit">
-          <i class="none"></i>
-        Apache Jackrabbit</a>
-            </li>
-            </ul>
-                
-                    
-                
-          <hr class="divider" />
-
-           <div id="poweredBy">
-                   
-    <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
-
-    
-    <div class="g-plusone" data-href="http://jackrabbit.apache.org/oak-doc/" data-size="tall" ></div>
-
-                   <div class="clear"></div>
-                            <div class="clear"></div>
-                            <div class="clear"></div>
-                             <a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy">
-        <img class="builtBy" alt="Built by Maven" src="./images/logos/maven-feather.png" />
-      </a>
-                  </div>
-          </div>
-        </div>
-        
-                
-        <div id="bodyColumn"  class="span9" >
-                                  
-            <!-- Licensed to the Apache Software Foundation (ASF) under one or more
-   contributor license agreements.  See the NOTICE file distributed with
-   this work for additional information regarding copyright ownership.
-   The ASF licenses this file to You 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. --><h1>Understanding the node state model</h1>
-<p>This article describes the <i>node state model</i> that is the core design abstraction inside the <tt>oak-core</tt> component. Understanding the node state model is essential to working with Oak internals and to building custom Oak extensions.</p>
-<div class="section">
-<h2>Background<a name="Background"></a></h2>
-<p>Oak organizes all content in a large tree hierarchy that consists of nodes and properties. Each snapshot or revision of this content tree is immutable, and changes to the tree are expressed as a sequence of new revisions. The MicroKernel of an Oak repository is responsible for managing the content tree and its revisions.</p>
-<p>The JSON-based MicroKernel API works well as a part of a remote protocol but is cumbersome to use directly in oak-core. There are also many cases where transient or virtual content that doesn&#x2019;t (yet) exist in the MicroKernel needs to be managed by Oak. The node state model as expressed in the NodeState interface in oak-core is designed for these purposes. It provides a unified low-level abstraction for managing all tree content and lays the foundation for the higher-level Oak API that&#x2019;s visible to clients.</p></div>
-<div class="section">
-<h2>The state of a node<a name="The_state_of_a_node"></a></h2>
-<p>A <i>node</i> in Oak is an unordered collection of named properties and child nodes. As the content tree evolves through a sequence of revisions, a node in it will go through a series of different states. A <i>node state</i> then is an <i>immutable</i> snapshot of a specific state of a node and the subtree beneath it.</p>
-<p>As an example, the following diagram shows two revisions of a content tree, the first revision consists of five nodes, and in the second revision a sixth node is added in one of the subtrees. Note how unmodified subtrees can be shared across revisions, while only the modified nodes and their ancestors up to the root (shown in yellow) need to be updated to reflect the change. This way both revisions remain readable at all times without the implementation having to make a separate copy of the entire repository for each revision.</p>
-<p><img src="nodestate-r1.png?raw=true" alt="two revisions of a content tree" /></p>
-<p>To avoid making a special case of the root node and therefore to make it easy to write algorithms that can recursively process each subtree as a standalone content tree, a node state is <i>unnamed</i> and does not contain information about it&#x2019;s location within a larger content tree. Instead each property and child node state is uniquely named within a parent node state. An algorithm that needs to know the path of a node can construct it from the encountered names as it descends the tree structure.</p>
-<p>Since node states are immutable, they are also easy to keep <i>thread-safe</i>. Implementations that use mutable data structures like caches or otherwise aren&#x2019;t thread-safe by default, are expected to use other mechanisms like synchronization to ensure thread-safety.</p></div>
-<div class="section">
-<h2>The NodeState interface<a name="The_NodeState_interface"></a></h2>
-<p>The above design principles are reflected in the <tt>NodeState</tt> interface in the <tt>org.apache.jackrabbit.oak.spi.state</tt> package of <tt>oak-core</tt>. The interface consists of three sets of methods:</p>
-
-<ul>
-  
-<li>Methods for accessing properties</li>
-  
-<li>Methods for accessing child nodes</li>
-  
-<li>The <tt>exists</tt> method for checking whether the node exists or is accessible</li>
-  
-<li>The <tt>builder</tt> method for building modified states</li>
-  
-<li>The <tt>compareAgainstBaseState</tt> method for comparing states</li>
-</ul>
-<p>You can request a property or a child node by name, get the number of properties or child nodes, or iterate through all of them. Even though properties and child nodes are accessed through separate methods, they share the same namespace so a given name can either refer to a property or a child node, but not to both at the same time.</p>
-<p>Iteration order of properties and child nodes is <i>unspecified but stable</i>, so that re-iterating through the items of a <i>specific NodeState instance</i> will return the items in the same order as before, but the specific ordering is not defined nor does it necessarily remain the same across different instances.</p>
-<p>The last three methods, <tt>exists</tt>, <tt>builder</tt> and <tt>compareAgainstBaseState</tt>, are covered in the next sections. See also the <tt>NodeState</tt> javadocs for more details about this interface and all its methods.</p></div>
-<div class="section">
-<h2>Existence and iterability of node states<a name="Existence_and_iterability_of_node_states"></a></h2>
-<p>The <tt>exists</tt> method makes it possible to always traverse any path regardless of whether the named content exists or not. The <tt>getChildNode</tt> method returns a child <tt>NodeState</tt> instance for any given name, and the caller is expected to use the <tt>exists</tt> method to check whether the named node actually does exist. The purpose of this feature is to allow paths like <tt>/foo/bar</tt> to be traversed even if the current user only has read access to the <tt>bar</tt> node but not its parent <tt>foo</tt>. As a consequence it&#x2019;s even possible to access content like a fictional <tt>/bar</tt> subtree that doesn&#x2019;t exist at all. A piece of code for accessing such content could look like this:</p>
-
-<div class="source">
-<pre>NodeState root = ...;
-
-NodeState foo = root.getChildNode(&quot;foo&quot;);
-assert !foo.exists();
-NodeState bar = foo.getChildNode(&quot;bar&quot;);
-assert bar.exists();
-
-NodeState baz = root.getChildNode(&quot;baz&quot;);
-assert !baz.exists();
-</pre></div>
-<p>The following diagram illustrates such a content tree, both as the raw content that simply exists and as an access controlled view of that tree:</p>
-<p><img src="nodestate-r2.png?raw=true" alt="content tree with and without access control" /></p>
-<p>If a node is missing, i.e. its <tt>exists</tt> method returns <tt>false</tt> and thus it either does not exist at all or is read-protected, one can&#x2019;t list any of its properties or child nodes. And on the other hand, a non-readable node or property will only show up when listing the child nodes or properties of its parent. In other words, a node or a property is <i>iterable</i> only if both it and its parent are readable. For example, attempts to list properties or child nodes of the node <tt>foo</tt> will show up empty:</p>
-
-<div class="source">
-<pre>assert !foo.getProperties().iterator().hasNext();
-assert !foo.getChildNodeEntries().iterator().hasNext();
-</pre></div>
-<p>Note that without some external knowledge about the accessibility of a child node like <tt>bar</tt> there&#x2019;s no way for a piece of code to distinguish between the existing but non-readable node <tt>foo</tt> and the non-existing node <tt>baz</tt>.</p></div>
-<div class="section">
-<h2>Building new node states<a name="Building_new_node_states"></a></h2>
-<p>Since node states are immutable, a separate builder interface, <tt>NodeBuilder</tt>, is used to construct new, modified node states. Calling the <tt>builder</tt> method on a node state returns such a builder for modifying that node and the subtree below it.</p>
-<p>A node builder can be thought of as a <i>mutable</i> version of a node state. In addition to property and child node access methods like the ones that are already present in the <tt>NodeState</tt> interface, the <tt>NodeBuilder</tt> interface contains the following key methods:</p>
-
-<ul>
-  
-<li>The <tt>setProperty</tt> and <tt>removeProperty</tt> methods for modifying properties</li>
-  
-<li>The <tt>getChildNode</tt> method for accessing or modifying an existing subtree</li>
-  
-<li>The <tt>setChildNode</tt> and <tt>removeChildNode</tt> methods for adding, replacing or removing a subtree</li>
-  
-<li>The <tt>exists</tt> method for checking whether the node represented by a builder exists or is accessible</li>
-  
-<li>The <tt>getNodeState</tt> method for getting a frozen snapshot of the modified content tree</li>
-</ul>
-<p>All the builders acquired from the same root builder instance are linked so that changes made through one instance automatically become visible in the other builders. For example:</p>
-
-<div class="source">
-<pre>NodeBuilder rootBuilder = root.builder();
-NodeBuilder fooBuilder = rootBuilder.getChildNode(&quot;foo&quot;);
-NodeBuilder barBuilder = fooBuilder.getChildNode(&quot;bar&quot;);
-
-assert !barBuilder.getBoolean(&quot;x&quot;);
-fooBuilder.getNodeChild(&quot;bar&quot;).setProperty(&quot;x&quot;, Boolean.TRUE);
-assert barBuilder.getBoolean(&quot;x&quot;);
-
-assert barBuilder.exists();
-fooBuilder.removeChildNode(&quot;bar&quot;);
-assert !barBuilder.exists();
-</pre></div>
-<p>The <tt>getNodeState</tt> method returns a frozen, immutable snapshot of the current state of the builder. Providing such a snapshot can be somewhat expensive especially if there are many changes in the builder, so the method should generally only be used as the last step after all intended changes have been made. Meanwhile the accessors in the <tt>NodeBuilder</tt> interface can be used to provide efficient read access to the current state of the tree being modified.</p>
-<p>The node states constructed by a builder often retain an internal reference to the base state used by the builder. This allows common node state comparisons to perform really well as described in the next section.</p></div>
-<div class="section">
-<h2>Comparing node states<a name="Comparing_node_states"></a></h2>
-<p>As a node evolves through a sequence of states, it&#x2019;s often important to be able to tell what has changed between two states of the node. This functionality is available through the <tt>compareAgainstBaseState</tt> method. The method takes two arguments:</p>
-
-<ul>
-  
-<li>A <i>base state</i> for the comparison. The comparison will report all changes necessary for moving from the given base state to the node state on which the comparison method is invoked.</li>
-  
-<li>A <tt>NodeStateDiff</tt> instance to which all detected changes are reported. The diff interface contains callback methods for reporting added, modified or removed properties or child nodes.</li>
-</ul>
-<p>The comparison method can actually be used to compare any two nodes, but the implementations of the method are typically heavily optimized for the case when the given base state actually is an earlier version of the same node. In practice this is by far the most common scenario for node state comparisons, and can typically be executed in <tt>O(d)</tt> time where <tt>d</tt> is the number of changes between the two states. The fallback strategy for comparing two completely unrelated node states can be much more expensive.</p>
-<p>An important detail of the <tt>NodeStateDiff</tt> mechanism is the <tt>childNodeChanged</tt> method that will get called if there can be <i>any</i> changes in the subtree starting at the named child node. The comparison method should thus be able to efficiently detect differences at any depth below the given nodes. On the other hand the <tt>childNodeChanged</tt> method is called only for the direct child node, and the diff implementation should explicitly recurse down the tree if it wants to know what exactly did change under that subtree. The code for such recursion typically looks something like this:</p>
-
-<div class="source">
-<pre>public void childNodeChanged(
-        String name, NodeState before, NodeState after) {
-    after.compareAgainstBaseState(before, ...);
-}
-</pre></div>
-<p>Note that for performance reasons it&#x2019;s possible for the <tt>childNodeChanged</tt> method to be called in some cases even if there actually are no changes within that subtree. The only hard guarantee is that if that method is <i>not</i> called for a subtree, then that subtree definitely has not changed, but in most common cases the <tt>compareAgainstBaseState</tt> implementation can detect such cases and thus avoid extra <tt>childNodeChanged</tt> calls. However it&#x2019;s important that diff handlers are prepared to deal with such events.</p></div>
-<div class="section">
-<h2>The commit hook mechanism<a name="The_commit_hook_mechanism"></a></h2>
-<p>A repository typically has various constraints to control what kind of content is allowed. It often also wants to annotate content changes with additional modifications like adding auto-created content or updating in-content indices. The <i>commit hook mechanism</i> is designed for these purposes. An Oak instance has a list of commit hooks that it applies to all commits. A commit hook is in full control of what to do with the commit: it can reject the commit, pass it through as-is, or modify it in any way.</p>
-<p>All commit hooks implement the <tt>CommitHook</tt> interface that contains just a single <tt>processCommit</tt> method:</p>
-
-<div class="source">
-<pre>NodeState processCommit(NodeState before, NodeState after)
-    throws CommitFailedException;
-</pre></div>
-<p>The <tt>before</tt> state is the original revision on which the content changes being committed are based, and the <tt>after</tt> state contains all those changes. A <tt>after.compareAgainstBaseState(before, ...)</tt> call can be used to find out the exact set of changes being committed.</p>
-<p>If, based on the content diff or some other inspection of the commit, a hook decides to reject the commit for example due to a constraint violation, it can do so by throwing a <tt>CommitFailedException</tt> with an appropriate error code as outlined in <a class="externalLink" href="http://wiki.apache.org/jackrabbit/OakErrorCodes">http://wiki.apache.org/jackrabbit/OakErrorCodes</a>.</p>
-<p>If the commit is acceptable, the hook can return the after state as-is or it can make some additional modifications and return the resulting node state. The returned state is then passed as the after state to the next hook until all the hooks have had a chance to process the commit. The resulting final node state is then persisted as a new revision and made available to other Oak clients.</p></div>
-<div class="section">
-<h2>Commit editors<a name="Commit_editors"></a></h2>
-<p>In practice most commit hooks are interested in the content diff as returned by the <tt>compareAgainstBaseState</tt> call mentioned above. This call can be somewhat expensive especially for large commits, so it&#x2019;s not a good idea for multiple commit hooks to each do a separate diff. A more efficient approach is to do the diff just once and have multiple hooks process it in parallel. The <i>commit editor mechanism</i> is used for this purpose. An editor is essentially a commit hook optimized for processing content diffs.</p>
-<p>Instead of a list of separate hooks, the editors are all handled by a single <tt>EditorHook</tt> instance. This hook handles the details of performing the content diff and notifying all available editors about the detected content changes. The editors are provided by a list of <tt>EditorProvider</tt> instances that implement the following method:</p>
-
-<div class="source">
-<pre>Editor getRootEditor(
-    NodeState before, NodeState after, NodeBuilder builder)
-    throws CommitFailedException;
-</pre></div>
-<p>Instead of comparing the given before and after states directly, the provider is expected to return an <tt>Editor</tt> instance to be used for the comparison. The before and after states are passed to this method so that the provider can collect generic information like node type definitions that is needed to construct the returned editor.</p>
-<p>The given <tt>NodeBuilder</tt> instance can be used by the returned editor to make modifications based on the detected content changes. The builder is based on the after state, but it is shared by multiple editors so during the diff processing it might no longer exactly match the after state. Editors within a single editor hook should generally not attempt to make conflicting changes.</p>
-<p>The <tt>Editor</tt> interface is much like the <tt>NodeStateDiff</tt> interface described earlier. The main differences are that all the editor methods are allowed to throw <tt>CommitFailedExceptions</tt> and that the child node modification methods all return a further <tt>Editor</tt> instance.</p>
-<p>The idea is that each editor <i>instance</i> is normally used for observing the changes to just a single node. When there are changes to a subtree below that node, the relevant child node modification method is expected to return a new editor instance for observing changes in that subtree. The editor hook keeps track of these returned &#x201c;sub-editors&#x201d; and recursively notifies them of changes in the relevant subtrees.</p>
-<p>If an editor is not interested in changes inside a particular subtree it can return <tt>null</tt> to notify the editor hook that there&#x2019;s no need to recurse down that subtree. And if the effect of an editor isn&#x2019;t tied to the location of the changes within the content tree, it can just return itself. A good example is a name validator that simply checks the validity of all names regardless of where they&#x2019;re stored. If the location is relevant, for example when you need to keep track of the path of the changed node, you can store that information as internal state of the returned editor instance.</p></div>
-<div class="section">
-<h2>Commit validators<a name="Commit_validators"></a></h2>
-<p>As mentioned, a common use for commit hooks is to verify that all content changes preserve the applicable constraints. For example the repository may want to enforce the integrity of reference properties, the constraints defined in node types, or simply the well-formedness of the names used. Such validation is typically based on the content diff of a commit, so the editor mechanism is a natural match. Additionally, since validation doesn&#x2019;t imply any further content modifications, the editor mechanism can be further restricted for this particular case.</p>
-<p>The abstract <tt>ValidatorProvider</tt> class and the related <tt>Validator</tt> interface are based on the respective editor interfaces. The main difference is that the validator provider drops the <tt>NodeBuilder</tt> argument to make it impossible for any validators to even accidentally modify the commit being processed. Thus, even though there&#x2019;s no performance benefit to using the <tt>Validator</tt> interface instead of <tt>Editor</tt>, it&#x2019;s a good idea to do so whenever possible to make the intention of your code clearer.</p></div>
-                  </div>
-            </div>
-          </div>
-
-    <hr/>
-
-    <footer>
-            <div class="container-fluid">
-              <div class="row span12">Copyright &copy;                    2012-2013
-                        <a href="http://www.apache.org/">The Apache Software Foundation</a>.
-            All Rights Reserved.      
-                    
-      </div>
-
-        
-        
-          
-    
-    
-    <div id="ohloh" class="pull-right">
-      <script type="text/javascript" src="http://www.ohloh.net/p/jackrabbit-oak/widgets/project_users_logo.js"></script>
-    </div>
-        </div>
-    </footer>
-  </body>
+<!DOCTYPE html>
+<!--
+ | Generated by Apache Maven Doxia at 2013-10-24
+ | Rendered using Apache Maven Fluido Skin 1.3.0
+-->
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <meta name="Date-Revision-yyyymmdd" content="20131024" />
+    <meta http-equiv="Content-Language" content="en" />
+    <title>Jackrabbit Oak - </title>
+    <link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
+    <link rel="stylesheet" href="./css/site.css" />
+    <link rel="stylesheet" href="./css/print.css" media="print" />
+
+      
+    <script type="text/javascript" src="./js/apache-maven-fluido-1.3.0.min.js"></script>
+
+    
+            </head>
+        <body class="topBarEnabled">
+          
+    
+    
+            
+    
+    
+    <a href="http://github.com/apache/jackrabbit-oak">
+      <img style="position: absolute; top: 0; right: 0; border: 0; z-index: 10000;"
+        src="https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png"
+        alt="Fork me on GitHub">
+    </a>
+  
+                
+                    
+                
+
+    <div id="topbar" class="navbar navbar-fixed-top ">
+      <div class="navbar-inner">
+                <div class="container-fluid">
+        <a data-target=".nav-collapse" data-toggle="collapse" class="btn btn-navbar">
+          <span class="icon-bar"></span>
+          <span class="icon-bar"></span>
+          <span class="icon-bar"></span>
+        </a>
+                
+                                <ul class="nav">
+                          <li class="dropdown">
+        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Overview <b class="caret"></b></a>
+        <ul class="dropdown-menu">
+        
+                      <li>      <a href="index.html"  title="Jackrabbit Oak">Jackrabbit Oak</a>
+</li>
+                  
+                      <li>      <a href="license.html"  title="License">License</a>
+</li>
+                  
+                      <li>      <a href="downloads.html"  title="Downloads">Downloads</a>
+</li>
+                  
+                      <li>      <a href="from_here.html"  title="From here">From here</a>
+</li>
+                          </ul>
+      </li>
+                <li class="dropdown">
+        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Concepts and architecture <b class="caret"></b></a>
+        <ul class="dropdown-menu">
+        
+                      <li>      <a href="overview.html"  title="Overview">Overview</a>
+</li>
+                  
+                      <li>      <a href="nodestate.html"  title="Understanding the node state model">Understanding the node state model</a>
+</li>
+                  
+                      <li>      <a href="microkernel.html"  title="Microkernel">Microkernel</a>
+</li>
+                  
+                      <li>      <a href="query.html"  title="Query">Query</a>
+</li>
+                  
+                      <li>      <a href="blobstore.html"  title="BlobStore">BlobStore</a>
+</li>
+                          </ul>
+      </li>
+                <li class="dropdown">
+        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Using Oak <b class="caret"></b></a>
+        <ul class="dropdown-menu">
+        
+                      <li>      <a href="use_getting_started.html"  title="Getting Started">Getting Started</a>
+</li>
+                  
+                      <li>      <a href="differences.html"  title="Differences to Jackrabbit 2">Differences to Jackrabbit 2</a>
+</li>
+                  
+                      <li>      <a href="dos_and_donts.html"  title="Dos and don'ts">Dos and don'ts</a>
+</li>
+                  
+                      <li>      <a href="when_things_go_wrong.html"  title="When things go wrong">When things go wrong</a>
+</li>
+                          </ul>
+      </li>
+                <li class="dropdown">
+        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developing Oak <b class="caret"></b></a>
+        <ul class="dropdown-menu">
+        
+                      <li>      <a href="dev_getting_started.html"  title="Getting Started">Getting Started</a>
+</li>
+                  
+                      <li>      <a href="participating.html"  title="Participating">Participating</a>
+</li>
+                  
+                      <li>      <a href="apidocs/index.html"  title="API docs">API docs</a>
+</li>
+                          </ul>
+      </li>
+                <li class="dropdown">
+        <a href="#" class="dropdown-toggle" data-toggle="dropdown">Links <b class="caret"></b></a>
+        <ul class="dropdown-menu">
+        
+                      <li>      <a href="http://jackrabbit.apache.org/oak"  title="Apache Jackrabbit Oak">Apache Jackrabbit Oak</a>
+</li>
+                  
+                      <li>      <a href="http://jackrabbit.apache.org/"  title="Apache Jackrabbit">Apache Jackrabbit</a>
+</li>
+                          </ul>
+      </li>
+                  </ul>
+          
+          
+          
+                   
+                      </div>
+          
+        </div>
+      </div>
+    </div>
+    
+        <div class="container-fluid">
+          <div id="banner">
+        <div class="pull-left">
+                                <div id="bannerLeft">
+                <h2>Oak Documentation</h2>
+                </div>
+                      </div>
+        <div class="pull-right">  </div>
+        <div class="clear"><hr/></div>
+      </div>
+
+      <div id="breadcrumbs">
+        <ul class="breadcrumb">
+                
+                    
+                  <li id="publishDate">Last Published: 2013-10-24</li>
+                  <li class="divider">|</li> <li id="projectVersion">Version: 0.11-SNAPSHOT</li>
+                      
+                
+                    
+      
+                            </ul>
+      </div>
+
+            
+      <div class="row-fluid">
+        <div id="leftColumn" class="span3">
+          <div class="well sidebar-nav">
+                
+                    
+                <ul class="nav nav-list">
+                    <li class="nav-header">Overview</li>
+                                
+      <li>
+    
+                          <a href="index.html" title="Jackrabbit Oak">
+          <i class="none"></i>
+        Jackrabbit Oak</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="license.html" title="License">
+          <i class="none"></i>
+        License</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="downloads.html" title="Downloads">
+          <i class="none"></i>
+        Downloads</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="from_here.html" title="From here">
+          <i class="none"></i>
+        From here</a>
+            </li>
+                              <li class="nav-header">Concepts and architecture</li>
+                                
+      <li>
+    
+                          <a href="overview.html" title="Overview">
+          <i class="none"></i>
+        Overview</a>
+            </li>
+                  
+      <li class="active">
+    
+            <a href="#"><i class="none"></i>Understanding the node state model</a>
+          </li>
+                  
+      <li>
+    
+                          <a href="microkernel.html" title="Microkernel">
+          <i class="none"></i>
+        Microkernel</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="query.html" title="Query">
+          <i class="none"></i>
+        Query</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="blobstore.html" title="BlobStore">
+          <i class="none"></i>
+        BlobStore</a>
+            </li>
+                              <li class="nav-header">Using Oak</li>
+                                
+      <li>
+    
+                          <a href="use_getting_started.html" title="Getting Started">
+          <i class="none"></i>
+        Getting Started</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="differences.html" title="Differences to Jackrabbit 2">
+          <i class="none"></i>
+        Differences to Jackrabbit 2</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="dos_and_donts.html" title="Dos and don'ts">
+          <i class="none"></i>
+        Dos and don'ts</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="when_things_go_wrong.html" title="When things go wrong">
+          <i class="none"></i>
+        When things go wrong</a>
+            </li>
+                              <li class="nav-header">Developing Oak</li>
+                                
+      <li>
+    
+                          <a href="dev_getting_started.html" title="Getting Started">
+          <i class="none"></i>
+        Getting Started</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="participating.html" title="Participating">
+          <i class="none"></i>
+        Participating</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="apidocs/index.html" title="API docs">
+          <i class="none"></i>
+        API docs</a>
+            </li>
+                              <li class="nav-header">Links</li>
+                                
+      <li>
+    
+                          <a href="http://jackrabbit.apache.org/oak" class="externalLink" title="Apache Jackrabbit Oak">
+          <i class="none"></i>
+        Apache Jackrabbit Oak</a>
+            </li>
+                  
+      <li>
+    
+                          <a href="http://jackrabbit.apache.org/" class="externalLink" title="Apache Jackrabbit">
+          <i class="none"></i>
+        Apache Jackrabbit</a>
+            </li>
+            </ul>
+                
+                    
+                
+          <hr class="divider" />
+
+           <div id="poweredBy">
+                   
+    <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
+
+    
+    <div class="g-plusone" data-href="http://jackrabbit.apache.org/oak-doc/" data-size="tall" ></div>
+
+                   <div class="clear"></div>
+                            <div class="clear"></div>
+                            <div class="clear"></div>
+                             <a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy">
+        <img class="builtBy" alt="Built by Maven" src="./images/logos/maven-feather.png" />
+      </a>
+                  </div>
+          </div>
+        </div>
+        
+                
+        <div id="bodyColumn"  class="span9" >
+                                  
+            <!-- Licensed to the Apache Software Foundation (ASF) under one or more
+   contributor license agreements.  See the NOTICE file distributed with
+   this work for additional information regarding copyright ownership.
+   The ASF licenses this file to You 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. --><h1>Understanding the node state model</h1>
+<p>This article describes the <i>node state model</i> that is the core design abstraction inside the <tt>oak-core</tt> component. Understanding the node state model is essential to working with Oak internals and to building custom Oak extensions.</p>
+<div class="section">
+<h2>Background<a name="Background"></a></h2>
+<p>Oak organizes all content in a large tree hierarchy that consists of nodes and properties. Each snapshot or revision of this content tree is immutable, and changes to the tree are expressed as a sequence of new revisions. The MicroKernel of an Oak repository is responsible for managing the content tree and its revisions.</p>
+<p>The JSON-based MicroKernel API works well as a part of a remote protocol but is cumbersome to use directly in oak-core. There are also many cases where transient or virtual content that doesn&#x2019;t (yet) exist in the MicroKernel needs to be managed by Oak. The node state model as expressed in the NodeState interface in oak-core is designed for these purposes. It provides a unified low-level abstraction for managing all tree content and lays the foundation for the higher-level Oak API that&#x2019;s visible to clients.</p></div>
+<div class="section">
+<h2>The state of a node<a name="The_state_of_a_node"></a></h2>
+<p>A <i>node</i> in Oak is an unordered collection of named properties and child nodes. As the content tree evolves through a sequence of revisions, a node in it will go through a series of different states. A <i>node state</i> then is an <i>immutable</i> snapshot of a specific state of a node and the subtree beneath it.</p>
+<p>As an example, the following diagram shows two revisions of a content tree, the first revision consists of five nodes, and in the second revision a sixth node is added in one of the subtrees. Note how unmodified subtrees can be shared across revisions, while only the modified nodes and their ancestors up to the root (shown in yellow) need to be updated to reflect the change. This way both revisions remain readable at all times without the implementation having to make a separate copy of the entire repository for each revision.</p>
+<p><img src="nodestate-r1.png?raw=true" alt="two revisions of a content tree" /></p>
+<p>To avoid making a special case of the root node and therefore to make it easy to write algorithms that can recursively process each subtree as a standalone content tree, a node state is <i>unnamed</i> and does not contain information about it&#x2019;s location within a larger content tree. Instead each property and child node state is uniquely named within a parent node state. An algorithm that needs to know the path of a node can construct it from the encountered names as it descends the tree structure.</p>
+<p>Since node states are immutable, they are also easy to keep <i>thread-safe</i>. Implementations that use mutable data structures like caches or otherwise aren&#x2019;t thread-safe by default, are expected to use other mechanisms like synchronization to ensure thread-safety.</p></div>
+<div class="section">
+<h2>The NodeState interface<a name="The_NodeState_interface"></a></h2>
+<p>The above design principles are reflected in the <tt>NodeState</tt> interface in the <tt>org.apache.jackrabbit.oak.spi.state</tt> package of <tt>oak-core</tt>. The interface consists of three sets of methods:</p>
+
+<ul>
+  
+<li>Methods for accessing properties</li>
+  
+<li>Methods for accessing child nodes</li>
+  
+<li>The <tt>exists</tt> method for checking whether the node exists or is accessible</li>
+  
+<li>The <tt>builder</tt> method for building modified states</li>
+  
+<li>The <tt>compareAgainstBaseState</tt> method for comparing states</li>
+</ul>
+<p>You can request a property or a child node by name, get the number of properties or child nodes, or iterate through all of them. Even though properties and child nodes are accessed through separate methods, they share the same namespace so a given name can either refer to a property or a child node, but not to both at the same time.</p>
+<p>Iteration order of properties and child nodes is <i>unspecified but stable</i>, so that re-iterating through the items of a <i>specific NodeState instance</i> will return the items in the same order as before, but the specific ordering is not defined nor does it necessarily remain the same across different instances.</p>
+<p>The last three methods, <tt>exists</tt>, <tt>builder</tt> and <tt>compareAgainstBaseState</tt>, are covered in the next sections. See also the <tt>NodeState</tt> javadocs for more details about this interface and all its methods.</p></div>
+<div class="section">
+<h2>Existence and iterability of node states<a name="Existence_and_iterability_of_node_states"></a></h2>
+<p>The <tt>exists</tt> method makes it possible to always traverse any path regardless of whether the named content exists or not. The <tt>getChildNode</tt> method returns a child <tt>NodeState</tt> instance for any given name, and the caller is expected to use the <tt>exists</tt> method to check whether the named node actually does exist. The purpose of this feature is to allow paths like <tt>/foo/bar</tt> to be traversed even if the current user only has read access to the <tt>bar</tt> node but not its parent <tt>foo</tt>. As a consequence it&#x2019;s even possible to access content like a fictional <tt>/bar</tt> subtree that doesn&#x2019;t exist at all. A piece of code for accessing such content could look like this:</p>
+
+<div class="source">
+<pre>NodeState root = ...;
+
+NodeState foo = root.getChildNode(&quot;foo&quot;);
+assert !foo.exists();
+NodeState bar = foo.getChildNode(&quot;bar&quot;);
+assert bar.exists();
+
+NodeState baz = root.getChildNode(&quot;baz&quot;);
+assert !baz.exists();
+</pre></div>
+<p>The following diagram illustrates such a content tree, both as the raw content that simply exists and as an access controlled view of that tree:</p>
+<p><img src="nodestate-r2.png?raw=true" alt="content tree with and without access control" /></p>
+<p>If a node is missing, i.e. its <tt>exists</tt> method returns <tt>false</tt> and thus it either does not exist at all or is read-protected, one can&#x2019;t list any of its properties or child nodes. And on the other hand, a non-readable node or property will only show up when listing the child nodes or properties of its parent. In other words, a node or a property is <i>iterable</i> only if both it and its parent are readable. For example, attempts to list properties or child nodes of the node <tt>foo</tt> will show up empty:</p>
+
+<div class="source">
+<pre>assert !foo.getProperties().iterator().hasNext();
+assert !foo.getChildNodeEntries().iterator().hasNext();
+</pre></div>
+<p>Note that without some external knowledge about the accessibility of a child node like <tt>bar</tt> there&#x2019;s no way for a piece of code to distinguish between the existing but non-readable node <tt>foo</tt> and the non-existing node <tt>baz</tt>.</p></div>
+<div class="section">
+<h2>Building new node states<a name="Building_new_node_states"></a></h2>
+<p>Since node states are immutable, a separate builder interface, <tt>NodeBuilder</tt>, is used to construct new, modified node states. Calling the <tt>builder</tt> method on a node state returns such a builder for modifying that node and the subtree below it.</p>
+<p>A node builder can be thought of as a <i>mutable</i> version of a node state. In addition to property and child node access methods like the ones that are already present in the <tt>NodeState</tt> interface, the <tt>NodeBuilder</tt> interface contains the following key methods:</p>
+
+<ul>
+  
+<li>The <tt>setProperty</tt> and <tt>removeProperty</tt> methods for modifying properties</li>
+  
+<li>The <tt>getChildNode</tt> method for accessing or modifying an existing subtree</li>
+  
+<li>The <tt>setChildNode</tt> and <tt>removeChildNode</tt> methods for adding, replacing or removing a subtree</li>
+  
+<li>The <tt>exists</tt> method for checking whether the node represented by a builder exists or is accessible</li>
+  
+<li>The <tt>getNodeState</tt> method for getting a frozen snapshot of the modified content tree</li>
+</ul>
+<p>All the builders acquired from the same root builder instance are linked so that changes made through one instance automatically become visible in the other builders. For example:</p>
+
+<div class="source">
+<pre>NodeBuilder rootBuilder = root.builder();
+NodeBuilder fooBuilder = rootBuilder.getChildNode(&quot;foo&quot;);
+NodeBuilder barBuilder = fooBuilder.getChildNode(&quot;bar&quot;);
+
+assert !barBuilder.getBoolean(&quot;x&quot;);
+fooBuilder.getNodeChild(&quot;bar&quot;).setProperty(&quot;x&quot;, Boolean.TRUE);
+assert barBuilder.getBoolean(&quot;x&quot;);
+
+assert barBuilder.exists();
+fooBuilder.removeChildNode(&quot;bar&quot;);
+assert !barBuilder.exists();
+</pre></div>
+<p>The <tt>getNodeState</tt> method returns a frozen, immutable snapshot of the current state of the builder. Providing such a snapshot can be somewhat expensive especially if there are many changes in the builder, so the method should generally only be used as the last step after all intended changes have been made. Meanwhile the accessors in the <tt>NodeBuilder</tt> interface can be used to provide efficient read access to the current state of the tree being modified.</p>
+<p>The node states constructed by a builder often retain an internal reference to the base state used by the builder. This allows common node state comparisons to perform really well as described in the next section.</p></div>
+<div class="section">
+<h2>Comparing node states<a name="Comparing_node_states"></a></h2>
+<p>As a node evolves through a sequence of states, it&#x2019;s often important to be able to tell what has changed between two states of the node. This functionality is available through the <tt>compareAgainstBaseState</tt> method. The method takes two arguments:</p>
+
+<ul>
+  
+<li>A <i>base state</i> for the comparison. The comparison will report all changes necessary for moving from the given base state to the node state on which the comparison method is invoked.</li>
+  
+<li>A <tt>NodeStateDiff</tt> instance to which all detected changes are reported. The diff interface contains callback methods for reporting added, modified or removed properties or child nodes.</li>
+</ul>
+<p>The comparison method can actually be used to compare any two nodes, but the implementations of the method are typically heavily optimized for the case when the given base state actually is an earlier version of the same node. In practice this is by far the most common scenario for node state comparisons, and can typically be executed in <tt>O(d)</tt> time where <tt>d</tt> is the number of changes between the two states. The fallback strategy for comparing two completely unrelated node states can be much more expensive.</p>
+<p>An important detail of the <tt>NodeStateDiff</tt> mechanism is the <tt>childNodeChanged</tt> method that will get called if there can be <i>any</i> changes in the subtree starting at the named child node. The comparison method should thus be able to efficiently detect differences at any depth below the given nodes. On the other hand the <tt>childNodeChanged</tt> method is called only for the direct child node, and the diff implementation should explicitly recurse down the tree if it wants to know what exactly did change under that subtree. The code for such recursion typically looks something like this:</p>
+
+<div class="source">
+<pre>public void childNodeChanged(
+        String name, NodeState before, NodeState after) {
+    after.compareAgainstBaseState(before, ...);
+}
+</pre></div>
+<p>Note that for performance reasons it&#x2019;s possible for the <tt>childNodeChanged</tt> method to be called in some cases even if there actually are no changes within that subtree. The only hard guarantee is that if that method is <i>not</i> called for a subtree, then that subtree definitely has not changed, but in most common cases the <tt>compareAgainstBaseState</tt> implementation can detect such cases and thus avoid extra <tt>childNodeChanged</tt> calls. However it&#x2019;s important that diff handlers are prepared to deal with such events.</p></div>
+<div class="section">
+<h2>The commit hook mechanism<a name="The_commit_hook_mechanism"></a></h2>
+<p>A repository typically has various constraints to control what kind of content is allowed. It often also wants to annotate content changes with additional modifications like adding auto-created content or updating in-content indices. The <i>commit hook mechanism</i> is designed for these purposes. An Oak instance has a list of commit hooks that it applies to all commits. A commit hook is in full control of what to do with the commit: it can reject the commit, pass it through as-is, or modify it in any way.</p>
+<p>All commit hooks implement the <tt>CommitHook</tt> interface that contains just a single <tt>processCommit</tt> method:</p>
+
+<div class="source">
+<pre>NodeState processCommit(NodeState before, NodeState after)
+    throws CommitFailedException;
+</pre></div>
+<p>The <tt>before</tt> state is the original revision on which the content changes being committed are based, and the <tt>after</tt> state contains all those changes. A <tt>after.compareAgainstBaseState(before, ...)</tt> call can be used to find out the exact set of changes being committed.</p>
+<p>If, based on the content diff or some other inspection of the commit, a hook decides to reject the commit for example due to a constraint violation, it can do so by throwing a <tt>CommitFailedException</tt> with an appropriate error code as outlined in <a class="externalLink" href="http://wiki.apache.org/jackrabbit/OakErrorCodes">http://wiki.apache.org/jackrabbit/OakErrorCodes</a>.</p>
+<p>If the commit is acceptable, the hook can return the after state as-is or it can make some additional modifications and return the resulting node state. The returned state is then passed as the after state to the next hook until all the hooks have had a chance to process the commit. The resulting final node state is then persisted as a new revision and made available to other Oak clients.</p></div>
+<div class="section">
+<h2>Commit editors<a name="Commit_editors"></a></h2>
+<p>In practice most commit hooks are interested in the content diff as returned by the <tt>compareAgainstBaseState</tt> call mentioned above. This call can be somewhat expensive especially for large commits, so it&#x2019;s not a good idea for multiple commit hooks to each do a separate diff. A more efficient approach is to do the diff just once and have multiple hooks process it in parallel. The <i>commit editor mechanism</i> is used for this purpose. An editor is essentially a commit hook optimized for processing content diffs.</p>
+<p>Instead of a list of separate hooks, the editors are all handled by a single <tt>EditorHook</tt> instance. This hook handles the details of performing the content diff and notifying all available editors about the detected content changes. The editors are provided by a list of <tt>EditorProvider</tt> instances that implement the following method:</p>
+
+<div class="source">
+<pre>Editor getRootEditor(
+    NodeState before, NodeState after, NodeBuilder builder)
+    throws CommitFailedException;
+</pre></div>
+<p>Instead of comparing the given before and after states directly, the provider is expected to return an <tt>Editor</tt> instance to be used for the comparison. The before and after states are passed to this method so that the provider can collect generic information like node type definitions that is needed to construct the returned editor.</p>
+<p>The given <tt>NodeBuilder</tt> instance can be used by the returned editor to make modifications based on the detected content changes. The builder is based on the after state, but it is shared by multiple editors so during the diff processing it might no longer exactly match the after state. Editors within a single editor hook should generally not attempt to make conflicting changes.</p>
+<p>The <tt>Editor</tt> interface is much like the <tt>NodeStateDiff</tt> interface described earlier. The main differences are that all the editor methods are allowed to throw <tt>CommitFailedExceptions</tt> and that the child node modification methods all return a further <tt>Editor</tt> instance.</p>
+<p>The idea is that each editor <i>instance</i> is normally used for observing the changes to just a single node. When there are changes to a subtree below that node, the relevant child node modification method is expected to return a new editor instance for observing changes in that subtree. The editor hook keeps track of these returned &#x201c;sub-editors&#x201d; and recursively notifies them of changes in the relevant subtrees.</p>
+<p>If an editor is not interested in changes inside a particular subtree it can return <tt>null</tt> to notify the editor hook that there&#x2019;s no need to recurse down that subtree. And if the effect of an editor isn&#x2019;t tied to the location of the changes within the content tree, it can just return itself. A good example is a name validator that simply checks the validity of all names regardless of where they&#x2019;re stored. If the location is relevant, for example when you need to keep track of the path of the changed node, you can store that information as internal state of the returned editor instance.</p></div>
+<div class="section">
+<h2>Commit validators<a name="Commit_validators"></a></h2>
+<p>As mentioned, a common use for commit hooks is to verify that all content changes preserve the applicable constraints. For example the repository may want to enforce the integrity of reference properties, the constraints defined in node types, or simply the well-formedness of the names used. Such validation is typically based on the content diff of a commit, so the editor mechanism is a natural match. Additionally, since validation doesn&#x2019;t imply any further content modifications, the editor mechanism can be further restricted for this particular case.</p>
+<p>The abstract <tt>ValidatorProvider</tt> class and the related <tt>Validator</tt> interface are based on the respective editor interfaces. The main difference is that the validator provider drops the <tt>NodeBuilder</tt> argument to make it impossible for any validators to even accidentally modify the commit being processed. Thus, even though there&#x2019;s no performance benefit to using the <tt>Validator</tt> interface instead of <tt>Editor</tt>, it&#x2019;s a good idea to do so whenever possible to make the intention of your code clearer.</p></div>
+                  </div>
+            </div>
+          </div>
+
+    <hr/>
+
+    <footer>
+            <div class="container-fluid">
+              <div class="row span12">Copyright &copy;                    2012-2013
+                        <a href="http://www.apache.org/">The Apache Software Foundation</a>.
+            All Rights Reserved.      
+                    
+      </div>
+
+        
+        
+          
+    
+    
+    <div id="ohloh" class="pull-right">
+      <script type="text/javascript" src="http://www.ohloh.net/p/jackrabbit-oak/widgets/project_users_logo.js"></script>
+    </div>
+        </div>
+    </footer>
+  </body>
 </html>
\ No newline at end of file



Mime
View raw message