I have a string set of field names populated as below:
Set<String> setAllCustomSettingFields = new Set<String>(); Map<String, Schema.SObjectType> gd = Schema.getGlobalDescribe(); for(String objectName : gd.keySet()){ Schema.SObjectType result = gd.get(objectName); if(result.getDescribe().isCustomSetting()){ Map<String, Schema.SObjectField> objectFields = result.getDescribe().fields.getMap(); for(String fieldString : objectFields.keySet()) { setAllCustomSettingFields.add(fieldString); } } }
All the strings in the set turn out to be all lowercase. It contains, for example, ‘api_url__c.’
However, setAllCustomSettingFields.contains('API_URL__c')
was false, whereas setAllCustomSettingFields.contains('api_url__c')
is true.
I have never seen that before, always thought all Apex is case insensitive, and the documentation on contains() doesn’t say anything about it.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Yes. Collection membership is case sensitive.
This applies to Sets:
If the set contains String elements, the elements are case-sensitive. Two set elements that differ only by case are considered distinct.
and to Maps:
Map keys of type String are case-sensitive. Two keys that differ only by the case are considered unique and have corresponding distinct Map entries. Subsequently, the Map methods, including put, get, containsKey, and remove treat these keys as distinct.
Method 2
Map keys and contains checks (and the same with Set
or List
) are always case sensitive, with the one exception of describes such as fields.getMap()
or Schema.getGlobalDescribe()
. However, as soon as you pull the keyset and put it somewhere else, you lose this magical property.
Method 3
From SF docs on Mapss:
Map keys of type String are case-sensitive. Two keys that differ only
by the case are considered unique and have corresponding distinct Map
entries. Subsequently, the Map methods, including put, get,
containsKey, and remove treat these keys as distinct.
From SF DOcs on Sets
If the set contains String elements, the elements are case-sensitive.
Two set elements that differ only by case are considered distinct.
Maps and Set uses Hash Collision and hence they treat keys as the case sensitive.
The only exception is Set<Id>
and Map<Id,Object>
Set<Id> setId = new Set<Id>{'0060D0000038F05'}; System.debug(setId.contains('0060D0000038F05QAE')); //Prints true
Method 4
This is not Apex case sensitivity but a String
case sensitivity.
You are comparing String
values in the Set
and thus it will always evaluate based on its equality which is case sensitive. So if your Set
contains api_url__c
, that’s not same as API_URL__C
.
From documentation:
- Uniqueness of set elements of user-defined types is determined by the equals and hashCode methods, which you provide in your classes. Uniqueness of all other non-primitive types is determined by comparing the objects’ fields.
- If the set contains String elements, the elements are case-sensitive. Two set elements that differ only by case are considered distinct.
Method 5
In addition to the map/set answers and not specifically Apex but relevant in Apex use of SOQL:
Platform Encryption deterministic encryption
When you use case-sensitive deterministic encryption, case matters. In
reports, list views, and SOQL queries on encrypted fields, the results
are case-sensitive. Therefore, a SOQL query against the Contact
object, where LastName = ‘Jones’, returns only Jones, not jones nor
JONES. Similarly, when the case-sensitive deterministic scheme tests
for unicity (uniqueness), each version of “Jones” is unique.Case-Insensitive Deterministic Encryption (Beta as of V45) and Custom Field
Allocations To allow case-insensitive queries, Salesforce stores a
lowercase duplicate of your data as a custom field in the database.
While these duplicates are necessary to enable case-insensitive
queries, they count against your total custom field count.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0