[
https://issues.apache.org/jira/browse/JCR-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463038
]
Stefan Guggisberg commented on JCR-322:
---------------------------------------
> Sandro Boehme commented on JCR-322:
> -----------------------------------
>
> >e.g. nodes of a specific type
> >could have been already created transiently but not yet saved, such nodes
> >could be in the transaction changelog, but not yet committed etc.
> If I do understand you right, this is some kind of a "lost update problem"
> because the transaction can use the node type with the commit after we
> unregistered/changed it.
> This means we should probably place a lock on the node type before
> unregistering or
> changing it and unlock it afterwards. The result of placing a lock on a node
> type would
> be that it cannot be used anymore and you get the lock token as soon as every
> use
> or transaction using this node type is finished.
> Even though it's practically not easy to implement, do you think that could
> theoretically work?
apart from being very difficult/messy to implement with the current
architecture
this would probably cause a serious and thus inacceptable performance
degredation.
> >just changing the type
> >of such nodes doesn't work since child items depend on their defining node
> >type
> >as well (-> Property#getDefiniton()#getDeclaringNodeType()). just changing
> >the node type is guaranteed to affect repository data integrity.
> You are right all dependent types (subtypes, childtypes) would also need to be
> changed to nt:base in this case.
i guess you got me wrong. i wasn't refering to the type hierarchy but to the
content
hierarchy, i.e. child nodes and properties of a node whose node type (or a
supertype
thereof) is about to be replaced. since a child node is defined within its
parent node's
node type this definition would need to be changed as well.
note that changing a node's node type to "nt:base" would in most cases lead to
an illegal
content structure since "nt:base" doesn't allow any child nodes and properties
(except
jcr:primaryType and jcr:mixinTypes of course). even changing to nt:unstructered
might
cause illegal structures since a parent node might not allow nt:unstructered on
child nodes.
> Support node type modification and removal
> ------------------------------------------
>
> Key: JCR-322
> URL: https://issues.apache.org/jira/browse/JCR-322
> Project: Jackrabbit
> Issue Type: New Feature
> Components: nodetype
> Affects Versions: 0.9, 1.0
> Reporter: Jukka Zitting
>
> There is currently no way to modify or remove registered node types. The
> existing reregister and unregister methods in NodeTypeRegistry throw "not
> yet implemented" exceptions for anything else than trivial node type changes.
> JSR 283 is working on an node type management API that we should ultimately
> implement.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
