namespace remapping

[Marcel Reutegger <mr...@adobe.com>]

hi,

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?

regards
 marcel

Re: namespace remapping

[Julian Reschke <ju...@gmx.de>]

On 2012-09-13 11:48, Marcel Reutegger wrote:
>> How is Jackrabbit handling this?
>
> Jackrabbit always stores names and path values with the namespace uri.

Oh, indeed. For some reason, I thought we're doing that only in JCR2SPI 
& friends.

(and yes, I still think we should have done exactly that in Oak as well)

Best regards, Julian

RE: namespace remapping

[Marcel Reutegger <mr...@adobe.com>]

> How is Jackrabbit handling this?

Jackrabbit always stores names and path values with the namespace uri.

regards
 marcel

Re: namespace remapping

[Julian Reschke <ju...@gmx.de>]

On 2012-09-13 10:47, Marcel Reutegger wrote:
> hi,
>
> 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?

Overall, it's bug^h^h^hlimitation. I believe the alternatives are:

- disallow remapping of prefixes (or of prefixes in use), or

- try to rewrite all of the content.

How is Jackrabbit handling this?

Best regards, Julian

Re: namespace remapping

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Sep 13, 2012 at 12:21 PM, Julian Reschke <ju...@gmx.de> wrote:
> On 2012-09-13 11:10, Jukka Zitting wrote:
>> 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
>
> We could do that for node names and some type of property values. But it
> would still potentially break other things (link identifiers in content,
> think a/@href).

Such content (value types other than NAME, PATH, etc.) is in any case
outside the scope of what the repository can be expected to do.
Remapping a namespace prefix in Jackrabbit 2.x won't affect such
content either.

BR,

Jukka Zitting

Re: namespace remapping

[Julian Reschke <ju...@gmx.de>]

On 2012-09-13 11:10, Jukka Zitting wrote:
> Hi,
>
> On Thu, Sep 13, 2012 at 10:47 AM, Marcel Reutegger <mr...@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
 > ...

We could do that for node names and some type of property values. But it 
would still potentially break other things (link identifiers in content, 
think a/@href).

Best regards, Julian

RE: namespace remapping

[Marcel Reutegger <mr...@adobe.com>]

Hi,

for now I'd prefer a simple solution, which just refuses to re-map
an existing namespace prefix to uri mapping.

regards
 marcel

> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Donnerstag, 13. September 2012 11:10
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: namespace remapping
> 
> Hi,
> 
> On Thu, Sep 13, 2012 at 10:47 AM, Marcel Reutegger
> <mr...@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

Re: namespace remapping

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Sep 13, 2012 at 10:47 AM, Marcel Reutegger <mr...@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