Work-Around for Self-Referencing Relationships

[NMoore42]

I've been running into the documented limitation of registerNew(record, field, parent) not supporting self-referencing relationships (i.e., child records that point to parent records of the same SObject type).

To work around this, I implemented a helper called SelfReferenceWork that uses the IDoWork interface to:

• Wait until after commitWork() inserts the parents
• Populate the self-reference lookup field on each child
• Insert all children with set AccessLevel

Basic usage looks like this:

SelfReferenceWork work = new SelfReferenceWork();
work.add(children, MyObject__c.Parent__c, parent);
uow.registerWork(work);
uow.commitWork();

Here is my SelfReferenceWork Class:

public class SelfReferenceWork implements fflib_SObjectUnitOfWork.IDoWork {
    private final List<SelfReferenceInsertTask> tasks = new List<SelfReferenceInsertTask>();
    private final AccessLevel accessLevel;

    public SelfReferenceWork() {
        this(false);
    }

    public SelfReferenceWork(Boolean runInSystemMode) {
        this.accessLevel = runInSystemMode ? System.AccessLevel.SYSTEM_MODE : System.AccessLevel.USER_MODE;
    }

    public void add(List<SObject> children, Schema.SObjectField relationshipField, SObject parent) {
        tasks.add(new SelfReferenceInsertTask(relationshipField, parent, children));
    }

    public void doWork() {
        Map<String, List<SObject>> childrenByType = new Map<String, List<SObject>>();

        for (SelfReferenceInsertTask task : tasks) {
            for (SObject child : task.children) {
                child.put(task.field, task.parent.Id);
                String key = String.valueOf(child.getSObjectType());
                if (!childrenByType.containsKey(key)) {
                    childrenByType.put(key, new List<SObject>());
                }
                childrenByType.get(key).add(child);
            }
        }
        
        for (List<SObject> children : childrenByType.values()) {
            Database.insert(children, accessLevel); // One dml statement per type
        }

    }

    private class SelfReferenceInsertTask {
        public Schema.SObjectField field;
        public SObject parent;
        public List<SObject> children;

        public SelfReferenceInsertTask(Schema.SObjectField field, SObject parent, List<SObject> children) {
            this.field = field;
            this.parent = parent;
            this.children = children;
        }
    }
}

Questions:

• Is this a valid and safe pattern for working around self-referencing constraints in Unit of Work?
• Does it conflict with anything internally in the UoW lifecycle that I might not be accounting for?
• Is there a better way to handle this use case that I'm missing?

[daveespo]

Hi @NMoore42

Good post and good questions. In short, yes, what you have proposed here is about as good as you can make self-referencing SObject relationship inserts.

Your example uses the relatively new User Mode to enforce CRUD/FLS (optionally) which would've historically been implemented via one of the methods discussed in past threads via an IDML implementation. (i.e. you probably would've wanted to use the same IDML implementation as your SOUOW so that the insert operation funneled through the same business logic as the SOUOW.commitWork())

There are the lifecycle 'hooks' such as onDMLFinished() that would not entirely be correctly triggered (i.e. DML isn't actually 'finished' until the IDoWork is finished) in your case above but you're not using those so I don't think there are any risks of regressions in future versions of SOUOW.

As I'm sure you can see, there is no general purpose way to support self-referencing relationships. Your case supports parent/child but would break down for grandchild, great-grandchild, etc. Or if there were multiple parents (i.e. a lookup to both a 'mother' and 'father' that needed to be populated on the child). As such, we have no plans to try to build this as a native feature into SOUOW.

[NMoore42]

Thank you for the clarification, Dave - I really appreciate it.

You’re absolutely right - my helper doesn’t support extended nesting such as grandchild or great-grandchild relationships. That said, for our use cases at least, about 95% involve only a single-level parent/child relationship, so it’s a practical fit.

If you scroll back through my post history on this thread (fair warning - I made quite a few edits over the past day), you’ll see I originally modified the fflib_SObjectUnitOfWork class to expose a getDML() method. I used that to call dmlInsert in a consistent way, but ultimately decided against modifying the Apex Commons source directly in our org.

Thanks again for the thoughtful response - and the vote of confidence. Do you think this is a discussion worth keeping open as a future reference for others who run into similar limitations with self-referencing inserts? I imagine others might benefit from the nuances covered here.

Also, as a side note Ryan Spicer says hi :)

[daveespo]

You could still use IDML without modifying SOUOW -- you can instantiate your IDML implementation and pass it into both the SOUOW constructor as well as your SelfReferenceWork constructor. Probably overkill for what you're doing here but just wanted to point out that you don't actually need to get into the internals of SOUOW to fish out the IDML that's used. And also there is a fflib_SObjectUnitOfWork.UserModeDML that would do what you need here.

We generally don't close discussions -- periodically a new idea or perspective is posted against an existing idea and I suspect the same will happen here.

And you can relay back a Hi to Ryan as well! Hope all is well!