[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735995#comment-17735995
]
Angela Schreiber commented on SLING-11910:
------------------------------------------
[~madamcin] , yes, that's the oak side of it. the only class you missed to
mention is
org.apache.jackrabbit.oak.plugins.nodetype.TypeRegistration
see
[https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/nodetype/TypeRegistration.java]
for the list of validation it performs.
would what you found in oak address your concerns specified in you comment at
https://issues.apache.org/jira/browse/SLING-11910?focusedCommentId=17735814&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17735814
?
then the repoinit implementation in jcr.repoinit could simply rely on the JCR
repository to prevent troublesome modifications instead of trying to spot them
itself, which it likely cannot do to the full extend the repository is actually
able to do it.
in other words: we were back at my original suggestion to either introduce an
optional flag 'allowUpdate' or introduce a new method. either way the repoinit
implementation would not perform any validation but would just pass the boolean
flag with the registration method (either on NodeTypeManagere or on the
CND-registration from commons which calls the NodeTypeManager)
> Repoinit should support 'allowUpdate' option with node type registration
> ------------------------------------------------------------------------
>
> Key: SLING-11910
> URL: https://issues.apache.org/jira/browse/SLING-11910
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Christian Schneider
> Priority: Major
>
> JCR node type registration as defined with
> {{NodeTypeManager#registerNodeType}} and
> {{NodeTypeManager.registerNodeTypes}} comes with a boolean flag that
> specifies how to handle existing node type definitions upon registration.
> However, Sling RepoInit does not support the 'allowUpdate' flag and there is
> no way to update an existing nodetype definition through RepoInit. Consumers
> of the API need to resort to programmatically update the node type using JCR
> API in a service.
> Here the extract from the specification (copied from
> https://developer.adobe.com/experience-manager/reference-materials/spec/jcr/2.0/19_Node_Type_Management.html):
> {quote}
> h3. 19.2.4 Registering a Node Type
> NodeType NodeTypeManager.
> registerNodeType(NodeTypeDefinition ntd, boolean allowUpdate)
> registers a new node type or updates an existing node type using the
> specified definition and returns the resulting NodeType object. Typically,
> the object passed to this method will be a NodeTypeTemplate (a subclass of
> NodeTypeDefinition) acquired from NodeTypeManager.createNodeTypeTemplate and
> then filled-in with definition information. If allowUpdate is true then an
> attempt to change the definition of an already registered node type will be
> made (see §19.2.4.1 {_}Updating Node Types{_}), otherwise an attempt to
> register a node type with the same name as an already registered one will
> fail immediately.
> NodeTypeIterator NodeTypeManager.
> registerNodeTypes(NodeTypeDefinition[] ntds,
> boolean allowUpdate)
> registers or updates the specified array of NodeTypeDefinition objects. This
> method is used to register or update a set of node types with mutual
> dependencies. It returns an iterator over the resulting NodeType objects. The
> effect of the method is “all or nothing”; if an error occurs, no changes are
> made.
> h4. 19.2.4.1 Updating Node Types
> A repository that supports node type management may support updates to a node
> type already in use as the type of an existing node. The extent of any such
> capability is implementation dependent. For example, some implementations may
> permit only changes which do not invalidate existing content, while others
> may allow larger changes. How any resulting incompatibilities are resolved is
> also implementation dependent. Any changes to the type of an exiting node
> must take effect in accordance with the _node type assignment behavior_ of
> the repository (see §10.10.1 {_}Node Type Assignment Behavior{_}).
> {quote}
> We would therefore suggestion to either add an optional 'allowUpdate' (or
> 'reregister') flag the existing {{register nodetypes}} command (default would
> be 'false' to ensure backwards compatible behavior) or introduce a new
> command {{{}reregister nodetypes{}}}.
>
> Original use case from [~cschneider]:
> My use case is to extend an existing mixin with an additional property.
> For new repositories this works but for existing repositories the existing
> mixin is unchanged.
> As my code requires the new property I get errors.
>
> So I propose that repoinit allows to update existing mixins (and possibly
> other structures).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
