jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@day.com>
Subject Re: Improving the reregistering of node types
Date Thu, 26 Aug 2010 12:23:03 GMT
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.  In order to
> change nodetypes we're currently using a module that can basically change any
> nodetype structure.  However 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.  By supplying a visitor or default pattern a user
> application could control how the changes would be carried out.  Even though
> some visiting might be necessary in these cases, because it would not require
> 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 solve

how would such an improved Node.setPrimaryNodeType look like?

> this.  But that also cannot handle renamed, and blindly drops subnodes and
> properties.  Especially 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 would
> be to extend the reregistering or setPrimaryNodeType functionality such that a
> broader set of operations can be supported, with a better performance than 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 changes
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.  Or is this just a path that you don't like JackRabbit see moving
> to.  I can see quite a few obstacles on the way of realizing some of the
> changes required, but what do you think would be most problematic to take?
>
> With kind regards,
> Berry van Halderen
> Hippo
>

Mime
View raw message