|
Current implementation provides to users 2 options for registering node types: node type definition file and node type list.
Expected behaviors
- Node type definition file
-
- Summary: Register & un-register node types from definition file are doable excepts data migration
- Old Node Type Definition
- Do nothing with registered node types from the old definition file.
- Un-register node types may cause of system failure when working with existing data. Beside that, we're supported updating node type definition of existing node type. So that, they still can re-use the node name if they want to but they need to be fully aware of what will happen.
- Pros: Don't need to care of data migration
- Cons: Unhandled node types
- New Node Type definition
- Node types are not registered => Register newly node types.
- Node types are registered => Compare of old definition and new definition
- Un-changes: Do nothing
- Modified:
- Un-register old node types
- Register node types with new definition
- Data migration => Show a warning. User should take care of their migration: versioning, indexing, required properties, backup & restore, etc
- Node types list: a list contains related node types and will be consumed by other modules. So that some node types are registered and may is part of the system. By comparing old node types list (registered content type definition) vs modified node types list, we will have 3 cases:
-
- Un-changes: Do nothing
- Added: Same as creation process.
- Removed: Do nothing
- Node type are not created by the content-type module: Do nothing
- Node types created by content-type module
- Same as discussion mentioned in "Old Node Type Definition" section above.
- Do nothing
Technical detail
Node Type Definition File
Contains all syntax of JCR node type definition, so that users have full control of node type modification. Note: Don't support CND at the moment
- Jackrabbit provides an API to register node type and allows updating. See NodeTypeManagerImpl#registerNodeTypes(java.io.InputStream, java.lang.String, boolean). However only trivial changes is supported
- Solution: unregister & register again. RegisterNodeTypeTask is a starting point.
- Disable references checking in existing contents. So that, we accepts the fact that : we don't handle data migration while changing node type definition. Could be introduced in a migration tool. See NodeTypeRegistry#disableCheckForReferencesInContentException
- Read node type definition by using NodeTypeReader. Register if it's non existing, else unregister & register if any changes. Detects by NodeTypeDefDiff#create
Node Types List
- All about of making decisions.
- No remark on technical side.
Concerns
- We need to make decisions on data migration. Should we support or not? If supported then how?
|