Cyclic Triggers about fflib-apex-common HOT 10 CLOSED

Firstly Chris, soooo sorry for the late reply, just about got over the DF hump fallout as i call it! ;-) You might be interested in the trigger state feature described in my blog here. The stack of invocations is not currently exposed but could be if we have a good use case here.

from fflib-apex-common.

Any thoughts @Autobat would the trigger state feature work for you, perhaps with a few tweaks?

from fflib-apex-common.

Hey Andy and the team,

Had a disastrous week with the flu sadly. I'm hoping to get some headspace this weekend to take a crack at this once I have fixed up the inbox from a week off. I have taken a look at the trigger state and I think we can get a nice approach for this that can be utilised by all.

I should be able to pen an approach for us to discuss soon,

from fflib-apex-common.

Ah sorry to hear that, glad your feeling better, look forward to reading your ideas. 👍

from fflib-apex-common.

Hey @afawcett

I have a working version, however, a weird issue.

In the test harness where we are passing an instance of the subclass to the trigger hander e.g. fflib_SObjectDomain.triggerHandler(fflib_SObjectDomain.TestSObjectStatefulDomainConstructor.class);

it is causing a very strange null pointer in a map where I store the Type vs. a class to track which methods are enabled.

Need to do some more investigation before i flip this over the SFDC support - have you seen anything similar?

private static Map<Type, TriggerEvent> TriggerEventByClass;
private static boolean isTriggerEventEnabled(Type domainClass)
{
    System.Debug(domainClass);  // not null
    System.Debug(TriggerEventByClass.keySet()); // no null pointer

    if(!TriggerEventByClass.containsKey(domainClass))    // this line fires a null pointer
    {
        TriggerEventByClass.put(domainClass, new TriggerEvent());
    }
    ... do stuff
}

Above is a snippet of the problem. Basically, if the domainClass is a subclass as we do in the test harness the System.Debug(...) lines show the correct values but the very next line gives a null pointer.

from fflib-apex-common.

p.s. it works when you pass it a top level class e.g. Accounts.class just only when it is a sub class it has the problem

from fflib-apex-common.

Just a thought, but is there by chance, a name collision with some other Apex class or static variable that happens to have the same name? Perhaps fully qualify your reference to TriggerEventByClass like ParentClass.TriggerEventByClass.

from fflib-apex-common.

Ah i wish it was as complex as that. All i needed was to step away from the computer for a bit and it was a stupid mistake on my end. I was referencing Trigger. e.g. isUpdate in my code which doesnt exist when we are mocking in the harness :)

#SchoolBoyError

from fflib-apex-common.

Created pull request #98

Sorry, i couldn't work out how to put the pull request here :/

Feedback welcomed on the approach

from fflib-apex-common.

Merged the PR, thanks for the submission! 👍

from fflib-apex-common.