Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <9C0FC4C8E9C29945B01766FC7F9D389816FE0B22BF@eurmbx01.eur.adobe.com>
References: 
 <9C0FC4C8E9C29945B01766FC7F9D389816FE0B22BF@eurmbx01.eur.adobe.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Thu, 13 Sep 2012 11:10:15 +0200
Message-ID: 
 <CAOFYJNbEU59LLJVBe3rA5_NRB1u74oVAOTnr0hj3Thzg2dUM5Q@mail.gmail.com>
Subject: Re: namespace remapping
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Thu, Sep 13, 2012 at 10:47 AM, Marcel Reutegger <mreutegg@adobe.com> wrote:
> remapping an existing namespace prefix in the namespace registry
> somewhat breaks existing content. say we create a node foo:test,
> save it and then remap prefix 'foo' to 'bar' in the namespace registry.
> reading the same node again will still return foo:bar, however 'foo'
> is not valid namespace prefix anymore. Was this done on purpose
> or this a bug?

The idea, not implemented yet, of how such things should be handled is
to have a commit hook that looks out for changes in registered
namespace prefixes and either a) simply rejects them, or b) goes
through all existing content (potentially with a query to save time)
and automatically updates all names and paths that contain modified
prefixes. Or the hook could just go through all content and reject the
prefix change if any content still refers to the old prefix (i.e. the
client would be responsible for removing or remapping all affected
content).

Alternatively we can implement namespace remappings by having two sets
of mappings. One for the original prefix mappings used in content and
another for prefix changes applied later. Those extra prefix changes
would not affect content in the repository itself, but would just be
applied as implicit session-local namespace remappings in all future
sessions.

BR,

Jukka Zitting