Move TriggerConfig to backfill package
#923
Conversation
TriggerConfig to backfill package
d784d1b to
41e72a7
Compare
Merging this branch will decrease overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. Changed unit test files
|
There was a problem hiding this comment.
Changes look fiine 👍
Can you explain a bit more the motivation behind this:
first step towards moving creating triggers right before the backfill process starts
is this so that we can consolidate trigger creation and only create one per table?
I thought we might have a migration orchestrator component with a signature roughly like:
type Something interface {
Process(actions ...DbAction) []DbAction
}which would take care of simplifying and combining multiple create trigger actions on the same table, as well as any other changes to the list of actions required before the actions get executed. Is this roughly where you think this refactoring is heading?
Yes. My goal is to create one up and down triggers per table. I would like to move the responsibility of creating and dropping triggers. Furthermore, I would like to move the management of
Yes and no. This refactoring is adjacent to the |
This PR is the first step towards moving creating triggers right before the backfill process starts.
In the long run, operations will only pass a trigger configuration to the
backfill.Backfillstruct, and it willtake care of loading the proper triggers for each table.