grabbit
grabbit copied to clipboard
TWCable
Improved handling of conflicting jcr:primaryType
Between AEM 5.6.1 and 6.1, there was a change in the jcr:primaryType (cq:Tag to nt:folder) for the node /etc/tags/forums. If you try to copy this node, the job will fail and you'll get the following error:
*ERROR* [clientJobLauncherTaskExecutor-6] org.springframework.batch.core.step.AbstractStep Encountered an error executing step clientJcrNodes in job clientJob
javax.jcr.nodetype.ConstraintViolationException: No matching property definition: jcr:description =
at org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.setProperty(NodeDelegate.java:522)
In this case, the situation seems fairly innocuous, and just a warning that the server jcr:PrimaryType does not match the existing client and either doing a no op or doing the conversion for that node would seem to work. This would allow you to avoid having to work around the node.
If this isn't possible, or desired, just a clearer error message indicating the primaryType doesn't match may be helpful to a user of Grabbit.
I think it's best that the scope of this be for improved logging.
I don't think we want to take the tool in the direction of data migration; or handling any specific, implicit data conversions.
On paper, I'm less concerned about the idea of, in general, always taking the server's primary types. We do similar things for "just take what's on the server for a node property's cardinality type." However, this may cross a line on the balance of introduced complexity to general practicality. Since the JCR primary type defines the node definition, we can't simply replace it like other properties. Lots of exisistential questions about the nature of the tool would have to be asked, and I just don't think we want to go there..
@sagarsane @jdigger looking in the Grabbit code, it looks like the particular logging requested as part of this ticket is still outstanding. Thinking this could be useful?
