For a current project I noticed that whenever I added one specific Salesforce object in a fieldmap (called Candidate_Selection_Phone_Screen__c), all of my fieldmaps mysteriously lost all of their object data (all /admin/settings/salesforce/fieldmap/%/edit screens were showing empty mappings, etc.). The only way to recover from this was to remove the "bad" field map and then re-save the "Object Setup" options (/admin/settings/salesforce/object).
I was at a loss for what was so problematic about using this one specific Salesforce object, and why it only led to an issue when it was part of a field map, as to opposed to simply being enabled in the Object Settings. To make a long story short, I finally realized that the "salesforce" field in DB table salesforce_field_map is type varchar(32). Of course Candidate_Selection_Phone_Screen__c is longer than 32 characters and was therefore getting truncated to Candidate_Selection_Phone_Screen.
This explained the issues with this specific mapping, but it did not explain why having this mapping active was breaking all my other mappings. Anyway, after some additional debugging I saw that salesforce_api_fieldmap_target_enabled was inadvertently corrupting the 'salesforce_api_enabled_objects' variable due to the fact that it could not find Candidate_Selection_Phone_Screen in Salesforce, which was then leading to all kinds of object integrity problems.
So fixing this would just require allowing the "salesforce" field in DB table salesforce_field_map to be a longer value (perhaps 64 or more characters). Of course this would be any easy adjustment, but I want to first ask if there is some reason why this field is currently limited to just 32 characters?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | salesforce-support_128_char_obj_names-1779116-6.patch | 1.46 KB | rjacobs |
Comments
Comment #1
kostajh commentedI'm not sure why it is set to 32. What do you think would be a reasonable limit, 64?
Comment #2
kostajh commentedComment #3
rjacobs commentedThanks kostajh,
I was just doing some informal research regarding the name limits in Salesforce, and though I can't find anything too official on the matter it looks like they may limit custom object names to 80 characters (which I guess would end up being 83 with the "__c"). Internal objects, on the other hand, may have a limit closer to 120 characters (though I'm not aware of any objects that actually come close to that limit).
I'm wondering if 128 characters makes sense. That seems like a nice "round" number that would suite all cases. Still, I'd be interested to know if anyone else has a more official answer to the character limits.
Comment #4
rjacobs commentedThis also applies to D7. I'm guessing the maintainers prefer a "backport" approach for these kinds of issues?
Comment #5
rjacobs commentedAh, sorry, looks like the trend for this project is not necessarily to backport, but to tag as "7.x-2.x"
Comment #6
rjacobs commentedPerhaps something like the following attached patch.
Comment #7
nicodv commentedHi there, I posted several support requests in the last 2 months but no one is giving me any help. Sorry to bump in this thread but just a minute of your time pointing me in the right direction could be enough.
I'm trying my best by myself with this issue, but obviously is not enough. My last post is this one http://drupal.org/node/1776308 and my problem: i made several batch imports and now neither import updates nor notifications can update the SF objects due to some startDate "delay"
Again: sorry to bump like this, but they have been 2 very long months trying to get this running.
Thanks
nico
Comment #8
rjacobs commentedI'm just checking up on this. I still can't find any official notes about the max character limit for custom object names in Salesforce. It looks like field names have a limit of 80 characters for custom objects and 120 characters for standard objects, but that does not say anything official about the object name itself.
From what I can see, it looks like the Salesforce admin GUI will only allow about 45 characters to be entered into the object name box when creating a new object, though that does not necessarily mean that the system would never have object names longer than that.
So I still vote for 128 characters (as it captured in the patch) as we can be pretty confident that would catch all cases (with room to spare). Is there any performance concern for using varchar(32) vs varchar(64) vs varchar(128)?
Comment #9
aaronbaumanclosing all 6.x issues