I Can Turn Off My Code. I Can't Turn Off Yours.
When developers set RunTrigger to false on Insert, Modify, or DeleteAll, they silently disable all subscribers including base app code and third-party extensions. The post argues that triggers should run by default because developers cannot know at compile time what logic they would disable, and proposes the platform should dynamically check at runtime whether anything is registered on a trigger before deciding whether to skip the expensive per-row execution.
Read it hereOpen in Claudehttps-stefanmaron-com-posts-modify-deserves-the-same-rule-as-validate--71cb43acff.md
post Stefan Maron
Key points
- Setting RunTrigger to false disables every subscriber on the table, including base app and third-party extension code, which the caller cannot know about when writing the code.
- In a journal import, merging three Modify calls per line into one gave about 20% speedup with no change in which triggers ran; removing Modify entirely (32%) was rejected because it would skip a third-party subscriber.
- Proposal: keep RunTrigger, but make true mean run the trigger only if something is registered, and otherwise fall back to the same bulk SQL operation used with false.
- A separate gap: ModifyAll cannot request field Validate logic, so respecting validate subscribers forces a slow record-by-record loop.
- Other systems differ: Rails, Django and Hibernate bypass callbacks on bulk paths, SQL Server, Oracle and PostgreSQL offer per-statement set-based triggers, and Salesforce Apex triggers always get batches of records.
Context
- Features: RunTrigger parameter, Insert trigger, Modify trigger, ModifyAll operation, Validate trigger, OnModify trigger
Source: Stefan Maron, community blog. Summary, key points and quotes are derived (CONTENT-NOTICE.md); read the original for the full text.