You need to sign in to do that
Don't have an account?
alaschgari
Dynamic/Generic SObject update method for Trigger
Hey folks,
I want to implement a method that is able to update a couple of objects which all have the same lookupfields:
Object1.LookupField1
Object1.LookupField2
Object2.LookupField1
Object2.LookupField2
My idea looks something like this:
trigger Object1Trigger on Object1 (before insert) { for(Object1 o1 : trigger.new) { o1 = updateLookups(o1); } } trigger Object2Trigger on Object2 (before insert) { for(Object1 o2 : trigger.new) { o2 = updateLookups(o2); } } updateLookups(SObject obj) { /* Logic to determine userId1 & userId2 */
//TODO
obj.put(LookupField1, userId1);
obj.put(LookupField2, userId2); return obj; }
Is this a good solution and if
YES: how do I have to implement it?
NO: which solution is even better?
Cheers
Josh :-)
That's what we did; many objects that have parallel fields, but possibly different names (because of managed packaging...). It's a very decent approach; it encourages code reuse, reduces overall code complexity, and makes it easier to isolate problems (and fix problems that affect all the various types at once). Our solution was to have a "field map" object. Here's a brief summary:
We use a "singleton" type setup so each entity will be initialized only once. This cuts down on our code being called multiple times (which will likely happen); there's actually close to 20 fields per entity, so this cuts down on the number of statements called.
So, when we get around to, for example, calculating the total price, we can do this:
Obviously, we have a bit more error-checking, but it should outline the usage fairly well.
All Answers
That's what we did; many objects that have parallel fields, but possibly different names (because of managed packaging...). It's a very decent approach; it encourages code reuse, reduces overall code complexity, and makes it easier to isolate problems (and fix problems that affect all the various types at once). Our solution was to have a "field map" object. Here's a brief summary:
We use a "singleton" type setup so each entity will be initialized only once. This cuts down on our code being called multiple times (which will likely happen); there's actually close to 20 fields per entity, so this cuts down on the number of statements called.
So, when we get around to, for example, calculating the total price, we can do this:
Obviously, we have a bit more error-checking, but it should outline the usage fairly well.
Hi sfdcfox!
Thank you very much for your solution!
Yes, this can be one of the possible solutions.
Does anyone have a second solution?