jongpie/apexuuid

A small library to provide UUID generation and validation in Apex

apexuuid's Issues

Chaining Sobjects to insert with single DML statement

Hello,
Great class!
I have been testing its implementation to chain creation of sObjects in one DML statement using an External ID and followed your documentation example with Account and Contact but my attempts are generating a DML exception.

static void testInsertChainedSObjectsInOneDML() {
        Exception dmlex;
        List<SObject> recordsToCreate = new List<SObject>();
        // Create 10 sample accounts
        for (Integer accountCount = 0; accountCount < 10; accountCount++) {
            // Create a new account & set a custom external ID text field called UUID__c
            Account newAccount = new Account(
                Name    = 'Account ' + accountCount,
                UUID__c = new UUID().getValue()
            );
            recordsToCreate.add(newAccount);

            // For each sample account, create 10 sample contacts
            for (Integer contactCount = 0; contactCount < 10; contactCount++) {
                // Instead of setting contact.AccountId with a Salesforce ID...
                // we can use an Account object with a UUID__c value to set the Contact-Account relationship
                Contact newContact = new Contact(
                    Account  = new Account(UUID__c = newAccount.UUID__c),
                    LastName = 'Contact ' + contactCount
                );
                recordsToCreate.add(newContact);
            }
        }
        // Sort so that the accounts are created before contacts (accounts are the parent object)
        recordsToCreate.sort();
        try {
            insert recordsToCreate;
        } catch(DMLException ex) {
            dmlex = ex;
        }
        System.assertEquals(null, dmlex, 'Expected no DML exception when chaining insert with UUID as external ID');
        // Verify that we only used 1 DML statement
        // System.assertEquals(1, Limits.getDmlStatements(), 'Expected only one DML statement');
    }

UUIDTest.testInsertChainedSObjectsInOneDML System.AssertException: Assertion Failed: Expected no DML exception when chaining insert with UUID as external ID: Expected: null, Actual: System.DmlException: Insert failed. First exception on row 10; first error: REQUIRED_FIELD_MISSING, Required fields are missing: [UUID__c]: [UUID__c]

It works if I insert in separate DMLs the lists I gathered for each sObject type, but, not with single one.
Any ideas?

Guid.isGuid method should use Guid.isEmpty

Currently, it calls String.isBlank(guid) instead of reusing the Guid.isEmpty method

Add support for generating other versions of UUIDs

The current implementation of the code uses v4 of the UUID standard, which is still a very reliable manner of generating a randomized, unique ID. However, there are several newer versions of UUIDs, each with their own use cases. The specs for the newer versions aren't fully finalized, but seem to be I'd like to expand the current code to provide a way to specify which version of UUID is generated.

Some resources that discuss the differences & benefits of some of the new versions:

• https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-04.html
• https://www.uuidtools.com/uuid-versions-explained
• https://blog.devgenius.io/analyzing-new-unique-identifier-formats-uuidv6-uuidv7-and-uuidv8-d6cc5cd7391a

At the moment, I'm considering these versions:

• Version 5 for consistently generated UUIDs: This version uses 2 inputs that will consistently produce the same UUID value when the same inputs are used
• Version 7 for sortable UUIDs: This version uses an Epoch timestamp as part of the UUID generation, which results in the UUIDs being sortable based on when they were created

There are a few other official & unofficial versions, but these seem like the most useful ones to focus on.

Add an invocable method to generate a UUID in Flow

Add version and variant

The implementation is not really conform with RFC 4122.
It doesn't not define a version nor a variant.

I guess it would be best do make it a version 4 variant 1 uuid. This will allow 122 or even 123 random bits.

If you are interested how it's done. Python has "ok readable" implementation of UUID version 4, see https://github.com/python/cpython/blob/master/Lib/uuid.py