Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

DML is not allowed in a constructor. Is there a known reason behind this limit?

I have been searching for the answer & haven't found anything which addresses the question. May be it's not documented anywhere(Or google doesn't know where it is).

share|improve this question
up vote 17 down vote accepted

The act of creation of object shouldn't have immediate dangerous side effects. If I'll create hundreds of your objects - will they all fire 1 DML?

This also holds true in Visualforce / any web context. The mere act of displaying some page (might be VF embedded in detail page layout, might be requested by some nasty Javascript like CSRF) shouldn't cause say deletes to run. You can work around it with stuff like <apex:page ... action="{!afterCtorHook}"> but it would be caught for example in Salesforce security review.

User should understand what he's doing ("are you sure you want to delete these 100 records?"), click something to confirm that this is really what he wants to do...

Check these too:

  1. (actually have a look at all items from, well worth a read).
  3. Try submitting your app to security scan? The report should provide some examples & explanations of the vulnerabilities:
share|improve this answer
Nail on the head... it's not allowed because it poses a huge security risk. – LaceySnr Feb 26 '14 at 22:38
Isn't the most likely reason that there is an underlying platform implementation limitation leaking out into the Apex code we write? That seems more likely to me than a feature being deliberately programmed in to protect users and then not documented. (I'm only commenting out of frustration at having to refactor some code out of a constructor that inserts a custom setting to get the default values set when the setting hasn't been managed.) – Keith C May 7 '14 at 17:42
@KeithC Don't think so, it's perfectly fine to have DML in constructors that aren't called in VF-related constructors: public class Hello { public Hello(){ insert new Account(Name = 'works'); } }. You'd have to ask somebody from SF to be sure :) But the concept of simply navigating to url (HTTP GET request) for all safe operations and confirming you know what you're doing (HTTP POST/PUT/PATCH/DELETE...) if you want to change the server's state is quite old: TL;DR: I believe it was a conscious design decision. – eyescream May 7 '14 at 18:00
@eyescream Thanks for commenting. Fully agree with you that e.g. GET should have no side affects. Just don't see the constructor as being special in a controller as property getters and other methods can also do DML that an end user might not expect. – Keith C May 7 '14 at 18:10

Using insert/update/delete in constructor is a bad practice in any language.

Establishing connection to DB - OK.
Constructor is used to create an object and initialize it's parameters; nothing more. I was trying to search for a better explanation but I failed.

I was taught to avoid using insert/update/delete operations when I worked with Java. It was enterprise project. The company had a lot of documents regarding how to code. And they have this rule to not use constructor for insert/update/delete. I think Select was ok. But I doubt it.

First, using DML in constructor will slow down initialization of your object. Second, it may fail and object just doesn't create at all. Second problem has it's roots from C/C++ where memory should be allocated for an object. In this case memory is allocated but object isn't created there.

share|improve this answer

A quick solution would be to place the dml operations in a single method that you call from the page action parameter.

for example VF page

<apex:page controller="pageController" action="{!doSomeDMLStuff}">

APEX Class

public pageController{

  private boolean doDML;

  public pageController(){

   //run some logic to decide if you need to execute dml statements

   if(logic = true){

      doDML= true;

  //the method called from the page action

  public pagereference doSomeDMLStuff(){

         //run DML statements 

     return null;

share|improve this answer
That's pretty much what @eyescream said... – Davin Casey Sep 8 '14 at 13:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.