Gagan
Gagan

Reputation: 1923

beatbox: Update custom field of multiple records at Account object

I am passing dict of something like

object_dict = {'Name': 'Sample Account', 'Type': 'Account', 'Id': '00001834fiBkAAO', 'score__c': '333'}

and want to update only 1 custom field ('score__c') at Account object but I am confused with the following 3 things:

  1. Account has 15 characters Id but i have 18 characters, apparently could be because the 15 characters one could not be unique to salesforce append 3 characters. But how do beatbox update deal with this? Will it update?

  2. Unlike upsert where key is passed with the service.upsert command, how does update work? Will it consider Name & ID as the composite key & then update the 'score__c' field?

  3. How does beatbox know which field to update amongst Name, Id & score__c?

Upvotes: 1

Views: 358

Answers (1)

hynekcer
hynekcer

Reputation: 15568

  1. The last 3 characters in 18 characters ID encode the upper/lower case of the previous characters, so that long IDs of objects can be compared for equivalency also in case insensitive programming languages. You can use what you get, either short or long ID. (Your ID is 16 characters long which is invalid.)

  2. The updated object is identified only by type and primary key id. All other names are updated columns. Therefore you can ignore "Name" if you don't wand update it.

  3. dtto


EDIT Explained "You can use what you get, either the short or long ID":
Everything on SFDC accepts both short or long ID (web interface, Apex, VisualForce, API, import data etc.) Internal apex code and the web URLs, views and reports in the browser use 15 characters because it is guaranteed processed case sensitive. Every output (like a backup, export from report, Developer Console or Salesforce API) is with 18 characters ID, to can be easily processed case insensitive e.g. by Excel.

You probably never need to strip or add the last 3 characters. The only problem could be if you combine an ID copied/pasted from the browser with exported data, but also the tools that prefer case insensitive search or compare, have some methods to do it case sensitive. You can also get the long ID e.g. by function CASESAFEID() in Apex or by SELECT Id from Account WHERE Id = 'short_id...' in Beatbox or offline by my function case_safe_id in Python, but I repeat that I have really never needed it. (except for a courious more accurate guess that a string could be a valid Salesforce ID or not: ID not found or Invalid ID reported by Salesforce) It is safe to simply case sensitive search a short ID contained in the sheet in Excel, because the ID have this structure:

ID structure:
    TTTII0XXXXXXXXXCCC
TTT = type of object
II = server instance where the data row was originally created
0 = it is still guaranteed zero at this position, but can be subject of change
XXXXXXXXX = ID of the row, jumping, but approximately increasing in a long-term scale
CCC = encoded case sensitive info

Therefore the match of the short ID searched in the long ID is possible only exactly at the beginning.

Edit 2 Salesforce recommends that you use the 18-character ID. (Developer Guide)

You can create a huge amount of similar 15-character IDs if you create many rows together by one call: svc.create(list_of_200_rows_data). It is interesting that ID and Lookup fields are compared case sensitively, even the short ones SELECT Id, Name FROM Contact WHERE AccountId = '0010000ID15CHAR' while text fields are compared case insensitively SELECT FirstName FROM Contact WHERE LastName='sMiTh'. Therefore if you ever save some 'old_id' for rows migrated from other Salesforce database (this must be saved as Text) they must be saved as 18-character ID

Upvotes: 2

Related Questions