function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
prodiprodi 

Autonumber not rolled back after test execution. Bug or working as designed?

I've had this issue for quite awhile but just assumed it was working as designed. But since I can't find any references on it in documentation, I thought I'd post here to be sure. Is this a bug or by design?

Running test cases which insert records into an object with an autonumber field cause the autonumber value to actually increment by the number of records inserted during the testmethod execution. After the test is complete, inserting a new record will result in an out-of-sequence autonumber value to be set on the new record. In other words, the autonumber values aren't rolled back during test execution.

In this simple example below the test method inserts 5 records into a custom object called "Book". The custom object contains a field called "Book Id" which is an autonumber field. After running this, the next record that is inserted into the Book object will have a Book Id 5 greater than the previously inserted record.

Code:
public class MyBookClass{

    public static void CreateNewBooks(List<String> titles){
        
        List<Book__c> booksToInsert = new List<Book__c>();
        
        for(String title : titles){
            Book__c b = new Book__c();
            b.Name = title;
            booksToInsert.add(b);
        }
        
        insert booksToInsert;
    }
    
    public static testmethod void CreateNewBookTest(){
        List<String> titles = new List<String>{'Title 1','Title 2','Title 3','Title 4','Title 5'};
        
        CreateNewBooks(titles);
        
        Integer count = [SELECT count() from Book__c where name in ('Title 1','Title 2','Title 3','Title 4','Title 5')];
        
        System.AssertEquals(5, count );
    }

}

 

TehNrdTehNrd
I can confirm this behavior also occurs when you have an auto number for the Name of an object.

I would think this behavior is not designed.
werewolfwerewolf
This is works as designed because test methods draw from the same autonumber pool as everything else (we had a similar thread on this topic a month ago).  Autonumbers are guaranteed to be unique, but not necessarily sequential -- there are a few cases like this where the sequence can skip some numbers.  Once you pull a number from the pool, it's gone forever, because the autonumber has no way of knowing who's going to commit -- it doesn't go back and say "aha, 9999 was rolled back so I'll give that to someone else now."

I suppose it's a valid feature request to have the test methods draw from a different autonumber pool, but that's just not how it works today.  In general, though, you shouldn't assume that all autonumbers will be exactly sequential.  You can assume that they're unique and that there's a 1-to-1 relationship between the autonumber and the time of creation (i.e. later times will have higher numbers), but it won't necessarily always be sequential.
TehNrdTehNrd
Great info. Thanks!
voutchervoutcher

Sorry to revive this but I find it really disturbing that testmethods can change something in live. The fact that testmethods should not change data in live is absolutely fundamental to salesforce, because it forces you to have them.

 

If someone chooses a number such as we have ABC-{000000}, then runs the testmethods many times over many months, what happens to the autonumber when we get to 999999? I was also hoping to be able to use this as an invoice number but since they need to be sequential we would need another way of doing this.

 

After talking to support and my account manager I have got no joy. We need a workaround, such as the one you suggest (to draw from a different autonumber pool). In a test method it is irrelevant what the autonumbers are since they are transient - or should be!

 

I don't expect testmethods to be leaving debris around my live system.

 

There is an idea here to be promoted but really this urgent!: http://sites.force.com/ideaexchange/ideaView?id=08730000000Br67AAC

 

Is there a list of things which testmethods can't roll back from a live system (creation of user accounts might be another one)? I think this is important information.

 

Thanks.

vinodshivharevinodshivhare

Appreciate your detailed explaination.

But I would take it as a bug in Salesforce becasue test methods are not meant to change the real data. It should be temporary. Why Salesforce has not mentioned this information anywhere in the technical documentation that Auto Number field will not be in a sequence, it may skip the numbers.

 

Due to this bug many of the projects required to re-write apex code to achieve real auto number functionality. Salesforce, please do something to resolve this bug.

Thank you. 

 

 

 

 

NikongNikong

Autonumbers are always incremental but from time to time will not be sequential.

Technical Explanation - SF will never attempt to make autonumbers consecutive (or Sequential). To do so, even in the simple case of saving one single object one-at-a-time, no two create operations can be executed in parallel.

For Example: The first create operation gets an autonumber value of 15 and attempts to save to the db and it fails. If the second creation operation is being executed in parallel and has started (attempting to save the autonumber value of 16) but cannot complete because 15 would be left out. As this situation generally involves more than just 2 records, one can see that the situation becomes much more complicated when we have bulk saves of multiple objects via the API where some of the rows may succeed and some may fail (due to apex triggers, for example). And when none of these complex operations can execute in parallel, the throughput will suffer and system resources will be tied up.

Therefore at this time, SF has chosen to maintain performance in our code than to guarantee sequential order of autonumber fields.