[nwcm]

Description

Currently Filter.equal() is not null safe. Calling Filter.with('Field__c').equal(couldBeNullVariable)

May result in Field__c = NULL which will include out of scope records unless additional .isNotNull().

This is not a breaking change, just an optional method which developers can chose to implement.

At the moment it dynamically chooses between Field__c = value and Field__c != NULL based on the input variable. We could add both conditions over this dynamic placement.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Test improvements
• CI/CD improvements

Changes Made

• Adds Filter.equalNullSafe(Object)
• Adds HavingFilter.equalNullSafe(Object)

Related Issues

n/a

Testing

• All existing tests pass (npm test)
• Added new tests for new functionality
• Tested in scratch org
• Linting passes (npm run lint)
• Code formatting is correct (npm run prettier:verify)

Screenshots

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code where necessary
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Additional Notes

[vercel]

@nwcm is attempting to deploy a commit to the Beyond The Cloud Team on Vercel.

A member of the Team first needs to authorize it.

[pgajek2]

Hi!

To do that, we can use ignoreWhen.

https://soql.beyondthecloud.dev/soql/api/soql-filter#ignorewhen

[nwcm]

Ah I missed that one. Thought it was only on FilterGroup.

Personally, I like the idea of having a clean single method on Filter but this will work

[pgajek2]

Ah I missed that one. Thought it was only on FilterGroup.

Personally, I like the idea of having a clean single method on Filter but this will work

We already have ignoreWhen(...), and introducing a new method would make the library harder to understand.
Additionally, ignoreWhen(...) makes the skipping condition explicit, while this method hides it.

I appreciate your contribution, but for those reasons, I’ll skip adding it.