• Daniel Morton 15
  • NEWBIE
  • 0 Points
  • Member since 2017

  • Chatter
    Feed
  • 0
    Best Answers
  • 5
    Likes Received
  • 0
    Likes Given
  • 1
    Questions
  • 2
    Replies
Hi,

Just in case this helps somebody! It tooks quite a bit of time to track this issue down.

We've had an issue with the sfdx force:data:tree:import command failing with a MALFORMED_ID message when trying to resolve references during data imports.   It turns out the issue was realated to our namespace, which has numbers in it, which the sfdx tool didn't handle.  
 
An example is :-

plan.json
 
[
    {
        "sobject": "i42as__testParent",
        "saveRefs": true,
        "files": [
            "parent.json"
        ]
    },
    {
        "sobject": "i42as__testChild",
        "resolveRefs": true,
        "files": [
            "child.json"
        ]
    }
]

parent.json 
 
{
    "records": [
        {
            "attributes": {
                "type": "i42as__testParent__c",
                "referenceId": "parentRef1"
            },
            "i42as__Message": "Hello"
        }
    ]
}

child.json
{
    "records": [{
        "attributes": {
            "type": "i42as__testChild__c",
            "referenceId": "testChildRef1"
        },
        "i42as__parent__c": "@parentRef1"
    }]
}

When run with the following command, this returns an error.  
 
sfdx  force:data:tree:import --plan plan.json

STATUSCODE    MESSAGE                                                                    FIELDS
────────────  ─────────────────────────────────────────────────────────────────────────  ───────────────────────────
MALFORMED_ID  Object: id value of incorrect type: @parentRef1  i42as__parent__c
=== testChildRef1 [1]

In turns out this was an error in the salesforce-alm library, the regex used to look for the @parentRef1 replacement was not expecting a number in the namespace.  I've managed to work around the issue by changing the file .local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/data/dataImportApi.js as follows;-
 
const jsonRefRegex = /[.]*["|'][A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;
const jsonRefRegex = /[.]*["|'][0-9A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;



 
Hi,

Just in case this helps somebody! It tooks quite a bit of time to track this issue down.

We've had an issue with the sfdx force:data:tree:import command failing with a MALFORMED_ID message when trying to resolve references during data imports.   It turns out the issue was realated to our namespace, which has numbers in it, which the sfdx tool didn't handle.  
 
An example is :-

plan.json
 
[
    {
        "sobject": "i42as__testParent",
        "saveRefs": true,
        "files": [
            "parent.json"
        ]
    },
    {
        "sobject": "i42as__testChild",
        "resolveRefs": true,
        "files": [
            "child.json"
        ]
    }
]

parent.json 
 
{
    "records": [
        {
            "attributes": {
                "type": "i42as__testParent__c",
                "referenceId": "parentRef1"
            },
            "i42as__Message": "Hello"
        }
    ]
}

child.json
{
    "records": [{
        "attributes": {
            "type": "i42as__testChild__c",
            "referenceId": "testChildRef1"
        },
        "i42as__parent__c": "@parentRef1"
    }]
}

When run with the following command, this returns an error.  
 
sfdx  force:data:tree:import --plan plan.json

STATUSCODE    MESSAGE                                                                    FIELDS
────────────  ─────────────────────────────────────────────────────────────────────────  ───────────────────────────
MALFORMED_ID  Object: id value of incorrect type: @parentRef1  i42as__parent__c
=== testChildRef1 [1]

In turns out this was an error in the salesforce-alm library, the regex used to look for the @parentRef1 replacement was not expecting a number in the namespace.  I've managed to work around the issue by changing the file .local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/data/dataImportApi.js as follows;-
 
const jsonRefRegex = /[.]*["|'][A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;
const jsonRefRegex = /[.]*["|'][0-9A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;



 
Hello There,

I am learning to use Salesforce DX. I set up the dev hub and trying to link namespace of my developer edition however, finding that the button itself is disabled The button name is - Link Namespace. Does anyone has went through such issue as well? Please, help me out.

Thanks.
Hey,

I will be finding this out for myself in the next little while, but meanwhile:  Does anybody know whether the following is possible?

Say we have a managed package, with NS prefix 'XXX' and the following class:

global virtual class baseClass {

    WebService String baseString;

    public baseClass () {
        baseString = 'bsaeClass instantiated';
    }
}

 We have this package deployed on an org, and now we want to do the following:

global class myClass extends XXX.baseClass {

    WebService String myString;

    public myClass () {
        super ();  // --- not sure if this is necessary ---
        myString = 'myClass instantiated';
    }
}

Is this legal?  Can you extend a virtual base class, if that class is sitting inside a managed package?  Can you even include virtual classes within a managed package, for that matter?
  • December 08, 2008
  • Like
  • 0