[jira] [Commented] (SLING-11910) Repoinit should support 'allowUpdate' option with node type registration
[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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
[jira] [Commented] (SLING-11910) Repoinit should support 'allowUpdate' option with node type registration
[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (SLING-11910) Repoinit should support 'allowUpdate' option with node type registration
[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735823#comment-17735823
]
Konrad Windszus commented on SLING-11910:
-
I think Oak and JR2 anyhow only ever allow Nodetype registration updates in
case they are additive i.e. don't make any existing node leveraging that type
invalid.
> 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)
[jira] [Commented] (SLING-11910) Repoinit should support 'allowUpdate' option with node type registration
[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735814#comment-17735814
]
Angela Schreiber commented on SLING-11910:
--
[~madamcin] , good point. I am not entirely sure though how you would find out
about the pure 'additive' nature of a node type definition. but as usual: feel
free to contribute a patch, it will be welcome.
> 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)
[jira] [Commented] (SLING-11910) Repoinit should support 'allowUpdate' option with node type registration
[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735801#comment-17735801
]
Mark Adamcin commented on SLING-11910:
--
[~cschneid] [~angela] I would ask that we add a stipulation that the
allowUpdate flag be passed to the NodeTypeManager only if the changes to
existing nodetype definitions are purely additive, so that on rollback to a
previous repoinit configuration, no attempt will be made to disallow properties
or child nodes that were created using the expanded nodetypes, which would
likely throw and prevent startup.
> 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)
[jira] [Commented] (SLING-11910) Repoinit should support 'allowUpdate' option with node type registration
[ https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17735271#comment-17735271 ] Angela Schreiber commented on SLING-11910: -- hi [~cschneider], i slightly adjusted the summary to capture the generic request. your need to have a mixin type definition updated is one example. but the same would apply for regular node types. > 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 > > 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)
