Closed homerlex closed 5 years ago
I've got a hint on this one. PTSectionc has a Lookup to PTSectionGroupc. The value for PTSectionGroupc on all the PTSectionc records is null in my data (expected). If I ignore this field in the import I don't get the error on the export. So, must have something to do with the null reference.
Looking at the details for the error
TypeError: Cannot read property 'get' of undefined
orgDestination.discovery.getSObjects.get.parents.forEach
Importer.js:181:86
I see the line 181 in JavaScript looks like this:
const destinationParentId = this.matchingIds.get(parent.sObj).get(sourceParentId);
And the error indicates that this.matchingIds.get(parent.sObj)
is null but unfortunately without being ble to run it and put a breakpoint (or make code changes to dump more stuff in the logs), I will not be able to know which parent.sObj
it was processing.
this.matchingIds: Map<string, Map<string, string>>
contains a map of sObjects with the old and new version of the record Ids.
It has to do something with the parent relationship of the PTSectionc sObject but I am not sure which parent.
P.S. I do not think the problem is with a field value being null, but with something that I have not completed yet (self-relationships).
I have not worked in Windows in a long time... but do you have a JavaScript file here:
(C:\\Users\\xxxx\\AppData\\Local\\sfdx\\plugins\\node_modules\\etcopydata\\lib\\@ELTOROIT\\Importer.js
Can you read it? Edit it? Maybe I could send you a version of the file with more debug information and you try running it.
Without running in a debugger (I don't have VSCode setup) I can tell you that the parent is PTSectionGroupc. Also this table is empty in my data do I guessing that this.matchingIds.get(parent.sObj)
evaluates to null.
And, yes, I can modify that file if you want to send me a custom version for debugging or testing a fix.
I think I understand a bit better now... I thought you were saying the foreign keys were null, not that the parent sObject had 0 records. That makes a huge difference!
In that case, ignoring the foreign key field will be the best solution.
I could also put some logic to detect this and avoid rrrors by ignoring the field
Explicitly ignoring is not a solution, but a workaround for the dataset I am currently working with. The parent table won't always be empty (in other dataset I'll need to work with). So having the code not blow up in this situation would be a good thing :-)
Thanks for doing this. Its looking very promising so far.
I’ll fix it ;-)
The issue has been solved, but npm has not been updated. Waiting for setting parameters (#4) to make new package.
Issue fixed.
I was able to successfully export a number of our custom objects. However, the import blew up:
If you need the export files I will need to send them to you privately.