How do we deal with Trigger not referencing the actual Object?

Question

Say I want to insert a Contact with some field, and have a Trigger that populates an other field. As a developer it always felt odd that the other field value is inaccessible without re-querying the object.

Contact c = new Contact();
c.FirstName = 'Foo';

insert c;
/**
 * trigger ContactTrigger on Contact (before insert) {
 *     Trigger.new[0].LastName = 'Bar';
 * }
 */

System.debug(c.FirstName); //'Foo' (I set this one above, so the value is ok)
System.debug(c.LastName);  //null  (This other field would have to be 're-queried')

If you're not interested in the fields set inside a Trigger, this might only be a rare annoyance. Just a slight confuser that the Trigger context is not the same reference as the insert operand.

Suppose for developer convenience, we truly wanted to share those references and access fields without re-querying. I guess we could work towards it by overextending the domain layer concept:

Contact c = new Contact();
c.FirstName = 'Foo';

new ContactModel(contact).insert();
/**
 * public class ContactModel {
 *
 *     private Contact contact;
 *
 *     public ContactModel(Contact contact) {
 *         this.contact = contact;
 *     }
 *
 *     public void insert() {
 *         // before-insert logic here...
 *
 *         this.Contact.LastName = 'Bar';
 *         insert this.Contact;
 *
 *         // after-insert logic here...
 *     }
 * }
 */

System.debug(c.FirstName); //'Foo' (I set this one above, so the value is ok)
System.debug(c.LastName);  //'Bar' (I set other field in domain layer, is ok)

So with that we share the same reference. And we see the fields alright. But it comes at a cost:

• must never use native insert or update (ironically, we could disable those with a trigger)
• must write ceremony triggers to invoke the same logic outside Apex (for GUI / API operations)
• we are reinventing a fundamental platform wheel (triggers) which gives me the heebie jeebies

Am about to open source a library dealing with this.

But is there an existing pattern or native solution?

Answer 1

I tend to use a cache for this purpose. The actual cache can be simple:

public class Cache {
    static Map<Id, SObject> records = new Map<Id, SObject>();
    public static void add(SObject data) {
        record.put(data.Id, data.clone(true, true, true, true));
    }
    public static void add(SObject[] data) {
        records.putAll(data.deepClone(true, true, true));
    }
    public static SObject[] get(Set<Id> recordIds) {
        Map<Id, SObject> temp = records.clone();
        temp.keySet().retainAll(recordIds);
        return temp;
    }
    public static SObject get(Id recordId) {
        return records.get(recordId);
}

Then, you simply use after-DML operations to store a copy of whatever you want:

trigger addContactsToCache on Contact (after insert, after update) {
    Cache.add(Trigger.new);
}

Finally, you can retrieve the data any time you want with either a single ID or a set of ID values.

My cache algorithm I wrote a while back was more complicated; it would query missing records if it found any were not in the cache, but if your goal is simply to have the data available outside the trigger context, static variables make this easy.

Answer 2

Been able to do some good noodling on this one in the last couple hours. With help from @ca_peterson and @andyinthecloud it's easy to recognize why Trigger and SObject are different references, necessarily and by design:

1. Those Trigger.New (etc) collections have to be garbage collected and having them hang around and permeate outside the commit context doesn't lend itself to transactions.

2. While we gotta re-query to see changes, it's taking for granted we don't have to pre-query the fields inside the trigger! All fields are populated for free. You can't have your cake and eat it :-)

3. Down at the metal, running Apex from a database trigger isn't trivial. Magically busting out to a high level language from a trigger should be appreciated as a cool/powerful thing in itself, as is.

4. Wrapping huge swathes of the Salesforce API (Database.xxx) is a bad idea likely to give birth to a leaky abstraction, notwithstanding the fact it doesn't account for Workflow Rules etc etc.