Swiss-army-knife Toolbox for Salesforce. Orchestrates base commands and assist users with interactive wizards to make much more than native sfdx + Allows you to define a complete CI/CD Pipeline and Schedule a daily Metadata backup & monitoring of your orgs
I tried to invoke the hardis:org:data:import command with an export.json containing objectSets but as isDeleteDataWorkspace() only iterates over a root objects key, it fails.
I realise merely updating this function to iterate over both objectSets and objects won't resolve the problem, as your commands make import and delete processes discrete with important checks.
I suggest a short-term solution is to throw an error from isDeleteDataWorkspace() if it finds exportFileJson.objectSets saying the feature isn't supported and redirecting users to use SFDMU directly (taking care to choose the right org).
In the medium/long term, perhaps a hardis:org:data:sets command could use your org-aware dataImportCommand without checking for deletion, but maybe only allow it to run as part of CICD with a -unsafe flag ("at your own risk") as it's quite temperamental. getDataWorkspaceDetail() could return isUsingObjectSets and error if hardis:org:data:sets isn't being used to maintain the safety you've baked in to the :import and :delete commands.
objectSets isn't a particularly well-designed feature as it runs completely discrete jobs with no contextual awareness for the whole config, so it doesn't reuse externalId from other objectSets etc. In my experience, it only works for those who have a data shape that doesn't rely on externalId and probably only have a basic hierarchy. However, its value lies in being able to do multiple operations on the same Object without having to do several manual runs, like being able to clean out data before doing a fresh import, so there's still a place for it to be implemented at some point, it just might become a support nightmare if users haven't grasped the nuances and limitations of the feature (like I learned the hard way...).
Hi Nicolas,
I tried to invoke the
hardis:org:data:importcommand with an export.json containing objectSets but as isDeleteDataWorkspace() only iterates over a root objects key, it fails.I realise merely updating this function to iterate over both objectSets and objects won't resolve the problem, as your commands make import and delete processes discrete with important checks.
I suggest a short-term solution is to throw an error from isDeleteDataWorkspace() if it finds
exportFileJson.objectSetssaying the feature isn't supported and redirecting users to use SFDMU directly (taking care to choose the right org).In the medium/long term, perhaps a hardis:org:data:sets command could use your org-aware dataImportCommand without checking for deletion, but maybe only allow it to run as part of CICD with a -unsafe flag ("at your own risk") as it's quite temperamental. getDataWorkspaceDetail() could return
isUsingObjectSetsand error ifhardis:org:data:setsisn't being used to maintain the safety you've baked in to the :import and :delete commands.objectSets isn't a particularly well-designed feature as it runs completely discrete jobs with no contextual awareness for the whole config, so it doesn't reuse externalId from other objectSets etc. In my experience, it only works for those who have a data shape that doesn't rely on externalId and probably only have a basic hierarchy. However, its value lies in being able to do multiple operations on the same Object without having to do several manual runs, like being able to clean out data before doing a fresh import, so there's still a place for it to be implemented at some point, it just might become a support nightmare if users haven't grasped the nuances and limitations of the feature (like I learned the hard way...).