Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 74.125.83.42 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=JUnl0hUEgYtJsIxc6U+N0tV1XZrh5w/fO7RSs4x5WxNKewxqs5jrin6JuyFCch12e7
         Nrw2dsSel3clNYo/NcUxc4n+trbxqU5h2MWRJ+bNGkBl3xivHqN7jyiTL7AWC1Dp6p3i
         hqusqj31whgLLoWpAoM5I/fzAuyUOjjp43I/o=
MIME-Version: 1.0
Sender: stefan.guggisberg@gmail.com
In-Reply-To: <AANLkTimZof-DosnE7oM0L71KB_UBa7UiGpU7FECeFKdO@mail.gmail.com>
References: <AANLkTimZof-DosnE7oM0L71KB_UBa7UiGpU7FECeFKdO@mail.gmail.com>
Date: Thu, 26 Aug 2010 14:23:03 +0200
Message-ID: <AANLkTinb7RSXHWU9OS-TN5Hqa7SU=dWgYDO9amLadPbs@mail.gmail.com>
Subject: Re: Improving the reregistering of node types
From: Stefan Guggisberg <stefan.guggisberg@day.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hi berry,

On Thu, Aug 26, 2010 at 11:47 AM, Berry van Halderen
<b.vanhalderen@1hippo.com> wrote:
> Dear all,
>
> In Jackrabbit, only "trivial" nodetype changes are supported(see

well, put differently, 'all but major node type changes are supported' ;)

> o.a.j.c.nodetype.NodeTypeDefDiff) to reregister node types. =A0In order t=
o
> change nodetypes we're currently using a module that can basically change=
 any
> nodetype structure. =A0However this is based on pure jcr interaction and
> therefor requires relative expensive copy actions.
>
> Better performance could be achieved if a broader set of changes could be
> supported by reregistering node types, such as adding mandatory fields or

the problem with e.g. adding mandatory fields is that it potentially leaves
inconsistent state, i.e. existing nodes lacking the mandatory field.

> renaming a field. =A0By supplying a visitor or default pattern a user
> application could control how the changes would be carried out. =A0Even t=
hough
> some visiting might be necessary in these cases, because it would not req=
uire
> jcr interaction, it could be executed much faster.

what would be visited? content changes triggered by type modifications?

>
> Alternatively a better support of Node.setPrimaryNodeType would also solv=
e

how would such an improved Node.setPrimaryNodeType look like?

> this. =A0But that also cannot handle renamed, and blindly drops subnodes =
and
> properties. =A0Especially for a structure of nodes, where both parent and=
 child
> nodes require a setPrimaryNodeType I can't see this to work at the moment=
.
>
> What we like to probe over the list, is what the inside crowd response wo=
uld
> be to extend the reregistering or setPrimaryNodeType functionality such t=
hat a
> broader set of operations can be supported, with a better performance tha=
n a
> pure JCR module as we have now.

i assume you are aware of https://issues.apache.org/jira/browse/JCR-322.

while i guess that we all agree that supporting non-trivial node type chang=
es
would be desirable, so far we've been unable to reach consensus on how to
implement it.

e.g. if we were able to efficiently and reliably determine whether a
given node type
is currently not being referenced, we could safely allow all types of
modifications.
however, this operation would IMO require a repository-wide lock, and that'=
s
the problematic part. same applies for node type changes that would trigger
content modifications (removed properties, added mandatory properties etc).

>
> Naturally you would all be worried about the amount of work involved, but=
 if

i am not so much worried about the amount of work. i just don't have found
the right approach...

cheers
stefan

> we could contribute most of this, would such an addition seen as valuable=
 and
> accepted. =A0Or is this just a path that you don't like JackRabbit see mo=
ving
> to. =A0I can see quite a few obstacles on the way of realizing some of th=
e
> changes required, but what do you think would be most problematic to take=
?
>
> With kind regards,
> Berry van Halderen
> Hippo
>