Feature/typeof by stackasaur · Pull Request #265 · beyond-the-cloud-dev/soql-lib

stackasaur · 2026-02-04T02:07:06Z

Description

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

Added support for TypeOf
Potentially breaking for user implementations as Queryable interface was modified

Related Issues

Fixes #235
Closes #

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

String query = SOQL.of(Event.sObjectType)
.with(
  SOQL.type.of(Event.WhatId)
  .when(Account.sObjectType).then(Account.Name)
  .when(Opportunity.sObjectType).then(Opportunity.Name)
  .whenElse('Name')
)
.toString();
System.debug(query);

// outputs
// SELECT TYPEOF What WHEN Account THEN Name WHEN Opportunity THEN Name ELSE Name END FROM Event

…truct clauses.

vercel · 2026-02-04T02:07:10Z

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

A member of the Team first needs to authorize it.

stackasaur · 2026-02-04T02:12:42Z

Haven't written unit tests yet.
Wanted some feedback on the code first as it's my first feature addition to this repo.

I added the neccesary classes to add the TypeOf fields as a component of SoqlFields as that seemed like the most logical place for the logic.

@pgajek2

pgajek2 · 2026-02-04T07:17:49Z

Haven't written unit tests yet. Wanted some feedback on the code first as it's my first feature addition to this repo.

I added the neccesary classes to add the TypeOf fields as a component of SoqlFields as that seemed like the most logical place for the logic.

@pgajek2

@stackasaur perfect!

I'll review it as soon I'll have time!

force-app/main/default/classes/standard-soql/SOQL.cls

pgajek2 · 2026-02-04T07:47:44Z

force-app/main/default/classes/standard-soql/SOQL.cls

+
+		// WHEN
+		Typeof when(SObjectType whenObject);
+


Could we remove that additional spaces? To have it similar to the other interfaces?

Interface itself looks great!

force-app/main/default/classes/standard-soql/SOQL.cls

pgajek2 · 2026-02-04T07:50:35Z

force-app/main/default/classes/standard-soql/SOQL.cls

+	private class SoqlTypeOf implements Typeof {
+		private String ofField;
+		private Map<SObjectType, SoqlFields> fieldsByType;
+		private SObjectType[] whenTypes;


Could we use List<SObjectType> to be consistent with the whole lib?

I'd argue that the whole lib should use SObjectType[] as that syntax saves a decent number of characters.

But I'll change it to meet the others. Changes to lower character count would be an entirely different issue.

hmm. It rather depends what you have to do.
Lists size is dynamic, Arrays size is fixed.
The whenTypes list should be dynamic in our case. We don't know the size as items can be added dynamically.

In Apex, there is no functional difference between the two though as Account[] accts = new List<Account>() and List<Account> accts = new Account[0]

You can't also denote an empty list as Account[] accts = new Account[]{} which I'd say implies the dynamic sizing while still cutting down on characters

I'll check performance, and if it's the same, what can I say: It's time to switch to [ ] 👯

pgajek2 · 2026-02-04T07:53:08Z

force-app/main/default/classes/standard-soql/SOQL.cls


+	private class SoqlTypeOf implements Typeof {
+		private String ofField;
+		private Map<SObjectType, SoqlFields> fieldsByType;


We can set the value here:

private Map<SObjectType, SoqlFields> fieldsByType new Map<SObjectType, SoqlFields>(); private List<SObjectType> whenTypes = new List<SObjectType>();

This was an intentional decision to answer the question "what should happen if you call of again?"

I figured it should either throw an exception or it should clear out the existing when/then clauses, and I chose the latter since I couldn't find many examples of the framework throwing exceptions for things like this.

Fair!

I would lean a little bit to an exception approach, as the syntax:

SOQL.Type.of(...).of(...)

looks a bit strange and shouldn't be allowed. I'll add another github issue to take care of other places.

Since there aren't any custom Exceptions in this class yet, how would you like to handle it?

I could probably argue that this is a use case for the built in IllegalArgumentException, but that may also feel a bit strange since it's essentially calling a setter twice which one would normally expect to work

We use the built-in exception QueryException.

throw new QueryException('My message');

We use it already in other places in the SOQL Lib.

force-app/main/default/classes/standard-soql/SOQL.cls

pgajek2 · 2026-02-04T07:58:11Z

force-app/main/default/classes/standard-soql/SOQL.cls

+			return this.of(ofField.getDescribe().getRelationshipName());
+		}
+
+		private SoqlFields getSoqlFields(SObjectType whenObject){


The getSoqlFields is private and it's invoked in methods below, could we move it at the end of the class?

There are two reasons:

It's private and doesn't have to be seen.

Read flow - it's invoked later, but defined first. It would have sense to have the definition below invocation.

pgajek2 · 2026-02-04T07:59:40Z

force-app/main/default/classes/standard-soql/SOQL.cls

+
+		private SoqlFields getSoqlFields(SObjectType whenObject){
+			SoqlFields ret = this.fieldsByType.get(whenObject);
+			if (ret == null){


Could we change the name from ret to something more descriptive?

pgajek2 · 2026-02-04T08:01:09Z

force-app/main/default/classes/standard-soql/SOQL.cls

+		private SoqlFields getElseFields(){
+			SoqlFields ret = this.elseFields;
+			if (ret == null){
+				ret = new SoqlFields(null);


Lets overload the SoqlFields constuctor so we don't have to pass SoqlFields.

Just create

public SoqlFields() { // default constructor }

pgajek2 · 2026-02-04T08:04:53Z

force-app/main/default/classes/standard-soql/SOQL.cls

+
+		public SoqlTypeOf when(SObjectType whenObject) {
+			if (!fieldsByType.containsKey(whenObject)){
+				this.fieldsByType.put(whenObject,null);


Why not like that?

this.fieldsByType.put(whenObject, new SoqlFields(whenObject.toString()));

so you don't have to do if (ret == null){ + you won't need this.getSoqlFields

public Typeof then(SObjectField field) { this.latestWhen().plainFields.add(field.toString()); return this; }

pgajek2 · 2026-02-04T08:13:06Z

force-app/main/default/classes/standard-soql/SOQL.cls

+			String suffix = ' END';
+
+			for (SObjectType t : this.whenTypes){
+				SoqlFields fields = this.fieldsByType.get(t);


Maybe let's create a new inner class TypeOfWhenThenFields?

I would like to avoid fieldStr = fieldStr.substring(7); // remove the SELECT
Another reason is that SoqlFields has a lot of logic that we doesn't need.

We will duplicate the logic a bit, but it's not a bad duplication.

The whole WHEN - THEN build can be hidden inside TypeOfWhenThenFields, so this one (SoqlTypeOf) will be just a wrapper that will add 'TYPEOF ' + this.ofField + ' '; and ' END';

public class TypeOfWhenThenFields public PlainFields plainFields = new PlainFields(); public RelationshipFields relationshipFields = new RelationshipFields(); }

I fully agree.

I was hesitant to create a new inner class for that as SoqlFields did meet the requirements with very little workaround needed, and I wanted to avoid adding what would be a significant number of characters.

Adding this will address several of your above comments.

No worries, when everything is ready we will chance spaces to tabs:

which significantly reduce number of characters. At the end of the day it won't be that bad, but I got you point.

pgajek2

I like it! Nice work!

If you disagree with anything, feel free to raise it.

stackasaur · 2026-02-04T18:24:32Z

@pgajek2

What is the expected behavior of situations like this:

TYPEOF can’t be used in queries with GROUP BY, GROUP BY ROLLUP, GROUP BY CUBE, and HAVING.

Throw Exceptions?
Let SFDC throw it when executed?
Clean in up for the user?

stackasaur · 2026-02-04T19:07:53Z

@pgajek2

I've addressed all of your comments

pgajek2 · 2026-02-04T19:41:01Z

@pgajek2

What is the expected behavior of situations like this:

TYPEOF can’t be used in queries with GROUP BY, GROUP BY ROLLUP, GROUP BY CUBE, and HAVING.

Throw Exceptions? Let SFDC throw it when executed? Clean in up for the user?

I would say: Let SFDC throw it when executed - as it's default behaviour, let's keep it in this way.

pgajek2 · 2026-02-04T19:44:25Z

@stackasaur all looks good, you can continue with the unit tests.

stackasaur · 2026-02-06T19:45:22Z

@pgajek2 ,

It doesn't seem that any relationship fields are valid in the Else clause, so I'm going to remove all of those

stackasaur · 2026-02-06T20:58:44Z

Tests completed. Updating documentation now

pgajek2 · 2026-02-07T08:12:47Z

force-app/main/default/classes/standard-soql/SOQL_Test.cls

 		Assert.areEqual(fromDate, binding.get('v5'), 'The binding variable should match the expected value.');
 	}

+	@IsTest


Could you adjust the test to be similar to the existing one?

I mean:

Add // Setup // Test // Verify comments to be consistent with the existing ones.

If possible, use chaining without a variable.

Use the clause in context of the whole SOQL Lib.

String query = SOQL.of(...) .with(SOQL.Type.of(Event.WhatId) .when(Account.sObjectType).then(Account.Id, Account.Name, Account.BillingCity, Account.BillingState, Account.BillingPostalCode) .when(Opportunity.sObjectType).then('Account',Account.Id, Account.Name, Account.BillingCity, Account.BillingState, Account.BillingPostalCode) .whenElse(new List<String>{'Name'}); .toString();

So do asserts in the context of the whole query rather than just test the individual typeof clause here?

pgajek2 · 2026-02-07T08:13:18Z

force-app/main/default/classes/standard-soql/SOQL_Test.cls

+
+	@IsTest
+	static void typeOfClassRelationshipFields(){
+		{


Does it work? You have brackets in weird places ;>

Test coverage all works.

I did the brackets to split the various overloads for the same method into different scopes. I could alternatively make separate methods.

I just normally do this when testing methods of slightly different signatures like this since apex lacks a better way to group together "sub tests"

stackasaur and others added 7 commits February 3, 2026 14:23

Type definitions for TypeOf class

ada6a4a

fix spacing

80d2373

Add TypeOfFields to SoqlFields and create builder methods to cons…

077daed

…truct clauses.

ignore empty fields collection inside with method

880ad57

add unit test

ff52e45

change isEmpty call to iterator.hasNext

a34b748

Merge branch 'beyond-the-cloud-dev:main' into feature/typeof

ab7048f

pgajek2 changed the base branch from main to release/v6.8.0 February 4, 2026 07:16

pgajek2 reviewed Feb 4, 2026

View reviewed changes

force-app/main/default/classes/standard-soql/SOQL.cls Show resolved Hide resolved

pgajek2 reviewed Feb 4, 2026

View reviewed changes

force-app/main/default/classes/standard-soql/SOQL.cls Show resolved Hide resolved

pgajek2 reviewed Feb 4, 2026

View reviewed changes

force-app/main/default/classes/standard-soql/SOQL.cls Show resolved Hide resolved

pgajek2 reviewed Feb 4, 2026

View reviewed changes

force-app/main/default/classes/standard-soql/SOQL.cls Show resolved Hide resolved

pgajek2 reviewed Feb 4, 2026

View reviewed changes

pgajek2 requested changes Feb 4, 2026

View reviewed changes

fix formatting issues

3907851

split TypeOfFields into new inner class TypeOfWhenThen

abb0c11

stackasaur added 4 commits February 6, 2026 14:50

remove relationship fields from whenElse

d1492ec

test coverage

6f17813

remove unused typeofs class

9cfcc2d

test coverage

4b0a43a

pgajek2 reviewed Feb 7, 2026

View reviewed changes

Uh oh!

Conversation

stackasaur commented Feb 4, 2026

Description

Type of Change

Changes Made

Related Issues

Testing

Screenshots

Checklist

Additional Notes

Uh oh!

vercel bot commented Feb 4, 2026

Uh oh!

stackasaur commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pgajek2 commented Feb 4, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pgajek2 Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pgajek2 Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pgajek2 left a comment

Choose a reason for hiding this comment

Uh oh!

stackasaur commented Feb 4, 2026

Uh oh!

stackasaur commented Feb 4, 2026

Uh oh!

pgajek2 commented Feb 4, 2026

Uh oh!

pgajek2 commented Feb 4, 2026

Uh oh!

stackasaur commented Feb 6, 2026

Uh oh!

stackasaur commented Feb 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stackasaur commented Feb 4, 2026 •

edited

Loading

pgajek2 Feb 4, 2026 •

edited

Loading

pgajek2 Feb 4, 2026 •

edited

Loading