feat: mutation triggers #65
Conversation
Codecov Report
@@ Coverage Diff @@
## master #65 +/- ##
==========================================
+ Coverage 94.43% 94.55% +0.12%
==========================================
Files 58 59 +1
Lines 1455 1488 +33
Branches 159 165 +6
==========================================
+ Hits 1374 1407 +33
Misses 79 79
Partials 2 2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
| /** | ||
| * A trigger is a way to specify entity mutation operation side-effects that run within the | ||
| * same transaction as the mutation itself. The one exception is afterCommit, which will run within | ||
| * the transaction if a transaction is supplied. | ||
| */ | ||
| export abstract class EntityMutationTrigger< | ||
| TFields, | ||
| TID, | ||
| TViewerContext extends ViewerContext, | ||
| TEntity extends ReadonlyEntity<TFields, TID, TViewerContext, TSelectedFields>, | ||
| TSelectedFields extends keyof TFields = keyof TFields | ||
| > { | ||
| abstract async executeAsync( | ||
| viewerContext: TViewerContext, | ||
| queryContext: EntityQueryContext, | ||
| entity: TEntity | ||
| ): Promise<void>; | ||
| } |
There was a problem hiding this comment.
Unless there's a meaningful reason to make this a class, plain async functions would be more lightweight:
type EntityMutationTrigger<
TFields,
TID,
TViewerContext extends ViewerContext,
TEntity extends ReadonlyEntity<TFields, TID, TViewerContext, TSelectedFields>,
TSelectedFields extends keyof TFields = keyof TFields
> = (
viewerContext: TViewerContext,
queryContext: EntityQueryContext,
entity: TEntity
) => Promise<void>;and the replacement for the constructor looks like:
function createThrowConditionallyTrigger<...>(parameters): EntityMutationTrigger<...> {
return async function throwConditionallyAsync() {
... close over parameters if needed
}
}There was a problem hiding this comment.
So far the class approach has worked out fairly cleanly for EntityPrivacyPolicyRule, especially since feeding params into the constructor is common as is having overloaded constructors. I can imagine that these may turn out to be reasonably similar, but I'll definitely keep it in mind as we start writing triggers and seeing usage patterns.
Why
This PR adds mutation triggers, which are similar to active record callbacks. They allow entity authors to specify code that runs before and after mutations, and a special callback that occurs after commit of the transaction.
Use cases:
Note that for now, this is separate from full entity validation (not yet implemented), but that will be done in a similar way. Depending on the transaction semantics we want for validation it may be exactly the same as
beforeAllbut it's unclear.How
Add ability to specify features, add tests.
Test Plan
Run tests.