[
https://issues.apache.org/jira/browse/SLING-11910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-11910:
-------------------------------------
Description:
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).
was:
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).
> 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)
