enapps-enorman commented on PR #22: URL: https://github.com/apache/sling-org-apache-sling-jcr-contentloader/pull/22#issuecomment-1568684852
@YegorKozlov I would be careful about expecting the output of the Sling GET JsonRenderer to be usable directly (without review and cleanup) as the input to the Sling POST import operation. FYI: Some of the known issues were under discussion with SLING-8375 The output from the ".tidy.json" selector only gives you a snapshot view of the current state (from the perspective of the current user), but not necessarily the JSON required to get to that state. So, I still don't think the output from the ".tidy.json" selector can be a reliable generic solution for a round-trip payload given all the unidirectional ways that the output can be customized. For example, there may be concerns with nodetype constraints, ACLs, resource decorators that have changed items or other things that could be in play during the import of that same payload. You are potentially getting much more than just the "JCR" nodes and properties in the json output. If you are truly only interested in a round-trip export/import scenario of only the JCR nodes and properties, then you may be better off using the xml or sysview.xml contentType for the round trip payload which would be more focused on just the JCR data. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
