Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type casting SObjectField to 'String' throws errors for non-string field types #495

Open
cnwork opened this issue Sep 10, 2024 · 3 comments · May be fixed by #496
Open

Type casting SObjectField to 'String' throws errors for non-string field types #495

cnwork opened this issue Sep 10, 2024 · 3 comments · May be fixed by #496

Comments

@cnwork
Copy link

cnwork commented Sep 10, 2024

Describe the bug
In the fflib_SObjects class, all these methods:

  • getStringFieldValues
  • getRecordsWithBlankFieldValues
  • getRecordsWithAllBlankFieldValues
  • getRecordsWithNotBlankFieldValues
  • getRecordsWithAllNotBlankFieldValues

are type casting SObjectFields to String. This is fine for all the field types that can be casted to String. However, type casting the number types to a String as all the above methods are doing: (String) record.get(field) throws errors like Invalid conversion from runtime type Integer to String, or Invalid conversion from runtime type Decimal to String

To Reproduce
Modify the generateDomain method from the fflib_SObjectsTest class to include in the Accounts the NumberOfEmployees field with a random Integer value and then run the entire test class. The tests for all the above methods will now fail.

Steps to reproduce the behavior:

  1. Create a regular scratch org
  2. Deploy ApexMocks and apex-common to it
  3. Modify the fflib_SObjectsTest.cls to include the NumberOfEmployees field with an interger value to one or more of the new Accounts and deploy the changes
  4. Run the entire test class
  5. Notice error: System.TypeException: Invalid conversion from runtime type Integer to String

Expected behavior
When the above methods are called for any field no matter its type, they correctly return the promised values or records.

Screenshots and text of error observed
Example of modified generateDomain method:

private static DomainAccounts generateDomain()
	{
		DomainAccounts domain = new DomainAccounts(
				new List<Account>
				{
						new Account(Name = 'A', ShippingCountry = 'USA'),
						new Account(Name = 'B', ShippingCountry = 'Ireland'),
						new Account(Name = 'C', ShippingCountry = 'UK', NumberOfEmployees = 10),
						new Account(Name = 'D', ShippingCountry = ''),
						new Account(Name = 'E', NumberOfEmployees = 20),
						new Account(),
						new Account(Name = 'G', ShippingCountry = 'Canada', NumberOfEmployees = 30)
				}
		);
		return domain;
	}

and the error for one of the existing tests (more are needed to be added to show the extent of the failures)

fflib_SObjectsTest.itShouldReturnRecordsWithAllFieldValues                    fflib_Objects       Fail     14%      System.TypeException: Invalid conversion from runtime type Integer to String                            
                                                                                                                    Class.fflib_SObjects.getRecordsWithAllNotBlankFieldValues: line 340, column 1                           
                                                                                                                    Class.fflib_SObjectsTest.DomainAccounts.selectPopulatedRecords: line 343, column 1                      
                                                                                                                    Class.fflib_SObjectsTest.itShouldReturnRecordsWithAllFieldValues: line 141, column 1                    8

Version
Did you try to reproduce the problem against the latest fflib-apex-common code?
Yes,

@cnwork cnwork linked a pull request Sep 10, 2024 that will close this issue
@cnwork
Copy link
Author

cnwork commented Sep 19, 2024

Would love to have some feedback on this and the PR.

Thanks,
Cristian

@daveespo @wimvelzeboer @ImJohnMDaniel

@ImJohnMDaniel
Copy link
Contributor

Apologies for the delay. I am DF24 and I am planning to get into this when I get back.

@cnwork
Copy link
Author

cnwork commented Sep 20, 2024

Apologies for the delay. I am DF24 and I am planning to get into this when I get back.

😄 I had a feeling that everyone was busy with DF24. Wish I was there too! Enjoy, no worries we can talk more next week.

Have a great DF24 and a nice weekend!
Cristian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants