Add versionedjob contrib package with basic versioning framework#39
Add versionedjob contrib package with basic versioning framework#39
versionedjob contrib package with basic versioning framework#39Conversation
83512d6 to
be6ba5e
Compare
be6ba5e to
13d81f2
Compare
Here, add a contrib package called `versionedjob` that brings in a very basic job versioning framework. The framework is very lightweight and users could easily have written it themselves, but it might be a little non-obvious how to leverage hooks to bring it in. Contrib should be a really nice home for this feature because it's a little too trivial to bother with in core, but it's nice for people to have a semi-official reference that's well-maintained.
13d81f2 to
aab9fad
Compare
|
Nice. @bgentry Want to take a look at this too? Might make a good blog post at least. |
bgentry
left a comment
There was a problem hiding this comment.
Seems like one good way to do this! Another is to implement a custom UnmarshalJSON on your arg type.
| } | ||
| ``` | ||
|
|
||
| The `VersionTransformer` implementation handles version upgrades one by one. Jobs which are multiple versions old can still be upgraded because multiple version changes can be applied in one go. This implementation uses `gjson`/`sjson` so that each change need only know a minimum about the data object in question and that unknown fields are retained. Other approaches are possible though, including using only Go's built-in `gjson` package. |
There was a problem hiding this comment.
I assume you meant encoding/json?
| The `VersionTransformer` implementation handles version upgrades one by one. Jobs which are multiple versions old can still be upgraded because multiple version changes can be applied in one go. This implementation uses `gjson`/`sjson` so that each change need only know a minimum about the data object in question and that unknown fields are retained. Other approaches are possible though, including using only Go's built-in `gjson` package. | |
| The `VersionTransformer` implementation handles version upgrades one by one. Jobs which are multiple versions old can still be upgraded because multiple version changes can be applied in one go. This implementation uses `gjson`/`sjson` so that each change need only know a minimum about the data object in question and that unknown fields are retained. Other approaches are possible though, including using only Go's built-in `encoding/json` package. |
I think one reason you might want to do this separately is that eventually all non-trivial version transformations tend to involved fetching data from the DB (this is what happened at Stripe anyway), so you probably want to have a struct you can add a DB pool to and access to This is definitely something to make clear in an eventual blog post though. |
Prepare a periodic release for rivercontrib. This largely contains a new lightweight version change framework as seen in #39.
Prepare a periodic release for rivercontrib. This largely contains a new lightweight version change framework as seen in #39. [skip ci]
Prepare a periodic release for rivercontrib. This largely contains a new lightweight version change framework as seen in #39. [skip ci]
Here, add a contrib package called
versionedjobthat brings in a verybasic job versioning framework. The framework is very lightweight and
users could easily have written it themselves, but it might be a little
non-obvious how to leverage hooks to bring it in.
Contrib should be a really nice home for this feature because it's a
little too trivial to bother with in core, but it's nice for people to
have a semi-official reference that's well-maintained.