[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735864#comment-17735864
]
Mark Adamcin commented on SLING-11910:
--------------------------------------
[~angela] I tried to trace the behavior from NodeTypeManager in oak and this is
what I found:
An attempt to save a new nodetype registration state that contains at least one
non-"trivial" change will cause a full content scan with a
ConstraintViolationException to be thrown if the change is incompatible [1].
The definition of a "trivial change" is implemented in the NodeTypeDefDiff
class in both jackrabbit-spi-commons [2] and oak-core [3].
{quote}A *{{TRIVIAL}}* modification has no impact on the consistency of
existing content. The following modifications are considered {{{}TRIVIAL{}}}:
* changing node type {{orderableChildNodes}} flag
* changing node type {{primaryItemName}} value
* adding non-{{{}mandatory{}}} property/child node
* changing property/child node {{protected}} flag
* changing property/child node {{onParentVersion}} value
* changing property/child node {{mandatory}} flag to {{false}}
* changing property/child node {{autoCreated}} flag
* changing specific property/child node {{name}} to {{*}}
* changing child node {{defaultPrimaryType}}
* changing child node {{sameNameSiblings}} flag to {{true}}
* weaken child node {{requiredPrimaryTypes}} (e.g. by removing)
* weaken property {{valueConstraints}} (e.g. by removing a constraint or by
making a specific constraint less restrictive)
* changing property {{defaultValues}}
* changing specific property {{requiredType}} to {{undefined}}
* changing property {{multiple}} flag to {{true}}
A *{{MAJOR}}* modification potentially _affects_ the consistency of existing
content. All modifications that are not *{{TRIVIAL}}* are considered
{*}{{MAJOR}}{*}.
{quote}
[1]
[https://github.com/apache/jackrabbit-oak/blob/4352bb31fe5ef74e8601ff1feb44d8f200bec303/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/nodetype/TypeEditorProvider.java#L81-L111]
[2]
[https://github.com/apache/jackrabbit/blob/37ede49f7161bf627c5ed3b50202184d7111f38c/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/nodetype/NodeTypeDefDiff.java]
[3]
[https://github.com/apache/jackrabbit-oak/blob/4352bb31fe5ef74e8601ff1feb44d8f200bec303/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/nodetype/NodeTypeDefDiff.java]
> 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)
