Replies: 2 comments
|
Hi @nwcm , looks interesting. Do you have any specific use case in mind? How do you imagine the extended class? Could you share a code example? |
0 replies
|
An example is wanting to stamp a UUID on DML or other systems where you may want to define fields via an extension of DML Something like this. If somewhere were to extend override and decided not to call super().method() then that would be their responsibility public inherited sharing class ProvenanceDML extends DML {
@TestVisible
private static final String FIELD_DOMAIN = 'Provenance_Domain__c';
private final ProvenanceRecord provenance;
/**
* @description Constructs a ProvenanceDML.
* @param provenance The provenance metadata to stamp on all inserted records.
*/
@NamespaceAccessible
public ProvenanceDML(ProvenanceRecord provenance) {
super();
this.provenance = provenance;
}
public override DML.Commitable toInsert(SObject record) {
stampProvenance(record);
return super.toInsert(record);
}
public override DML.Commitable toInsert(List<SObject> records) {
for (SObject record : records) {
stampProvenance(record);
}
return super.toInsert(records);
}
public override DML.OperationResult insertImmediately(SObject record) {
stampProvenance(record);
return super.insertImmediately(record);
}
public override DML.OperationResult insertImmediately(List<SObject> records) {
for (SObject record : records) {
stampProvenance(record);
}
return super.insertImmediately(records);
}
private void stampProvenance(SObject record) {
try {
record.put(FIELD_DOMAIN, this.provenance.getDomainIdentifier());
} catch (SObjectException e) {
throw new ProvenanceException(
'Failed to stamp provenance on ' + record.getSObjectType() + ': ' + e.getMessage()
);
}
}
} |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Thought I'll raise a discussion to see if this would be something dml-lib would want/allow.
To allow extending DML the class and methods would need to be virtual. This could allow custom implementations overriding some of the default behaviour, in an example case always populating
x__cfield on sobjects or similar neatly withTaggedDMLclass or similar.I don't foresee any issues on the lib side adding this. Obviously, there are considerations for anyone extending the DML class, if done unsafely.
An alternative is enhancing hook or similar to allow pre commit functions to modify record state, but that seems more complicated and risky on the lib side.
All reactions