Improve handling of self-referencing lookups by force:data:tree commands

[wef-maros]

Is your feature request related to a problem? Please describe.
When trying to migrate records using force:data:tree:export and import commands, the import fails on objects which have a self-referencing lookup (i.e. lookup pointing to the same object).
The error is this.

ERROR running force:data:tree:import:  Found references in file, but no reference-id content found (records.json). Was parent SObjects saved first?

What are you trying to do
I'm trying to migrate records which are in a hierarchy within one object.

Describe the solution you'd like
What I would like to happen is that either the import command saves and resolves references also during import of a single file. In other words, it wouldn't require to save parent records in first import and then the child records in second import.
Or alternatively, I would like the export command which runs a single query on an object with self-referencing lookup to create two (or as many as necessary) separate files for import together with import plan for those files.

Describe alternatives you've considered
I've considered, and made a working prototype of, a script which exports the data in JSON format and from that prepares the files in format usable for force:data:tree:import command. What I would like to avoid is having a custom script to maintain if there is a way the same could be achieved with just Salesforce CLI.

Additional context
I'm happy to add more information on request.

[iandrosov]

This is 1 year later I think this functionality still not supported automatically to handle Self-referenced objects

[JDX-DD]

Having the exact same issue, even tried relating all hierarchy records to a common parent with no luck. @wef-maros Is your script that prepares these types of files publicly available? If not could you explain the format the files need to be in to make this work? It would be very helpful. Thanks

[srlawr]

This error certainly still exists, and I could find no solution/work around before stumbling across this report.

My only solution was to add text fields for the REF name and REF to the object, import it all like that and then run some anonymous apex to load up all the records, and find the SF ID of the target REF and put it into the field 🤦 honestly, for the 17 records I wanted imported into this object for Scratch work... it would probably be easier to just update it by hand every 30 days.

[CiaranShocks]

So I managed to find a workaround for importing when using a plan.json file! Basically you need to separate the parent record into a file on its own and direct the plan.json file to import this first. See the plan attached below:

[ { "sobject": "Account", "saveRefs": true, "resolveRefs": false, "files": [ "Accounts1.json" ] }, { "sobject": "Account", "saveRefs": true, "resolveRefs": true, "files": [ "Accounts2.json" ] }, ]

This just makes sure the parent is already added before trying to reference it in the Accounts2.json file!

[mshanemc]

the new data export beta tree command will now export these types of things correctly.

The import command would need to be rewritten here to allow a foundRef which isn't in the refMap but is somewhere else in the file.

OR, the refMap adds for the file should happen BEFORE the files are parsed, similar to how the new export command builds the refMap before trying to convert refs<=>ID