ENH: Generalize schema configuration and dumping #952
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mferrera
force-pushed
the
dump-product-schema
branch
from
db3b4fa to
f6720fd
Compare
tnatt
reviewed
Jan 6, 2025
mferrera
force-pushed
the
dump-product-schema
branch
2 times, most recently
from
f4d578d to
09b96d6
Compare
tnatt
approved these changes
Jan 7, 2025
|
|
||
| @classmethod | ||
| def __init_subclass__(cls, **kwargs: dict[str, Any]) -> None: | ||
| super().__init_subclass__(**kwargs) |
There was a problem hiding this comment.
I always learn something new 🙂 never seen this __init_subclass__ before
There was a problem hiding this comment.
It didn't feel quite right to use use a Pydantic model as an abstract interface with methods (and Pydantic also didn't seem to like using an ABC as a mixin), so Pydantic-light it was
This creates a pattern for defining schema versions, filenames, and paths. These can then be used throughout the code without being hardcoded strings. The dev and prod URLs are also now present in the code. In the main branch the `$id` URLs now point to the dev enviroment, as this environment tracks main anyway. The idea is that these URLs switching to the production ones will be a step during the promotion to the staging environment. Currently this is done "secretly" with a shell script but as the number of schemas grows, I think it makes more sense to have this be explicit.
mferrera
force-pushed
the
dump-product-schema
branch
from
09b96d6 to
5e00283
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Toward #895 + schema versioning
This creates a pattern for defining schema versions, filenames, and paths. These can then be used throughout the code without being hardcoded strings.
The dev and prod URLs are also now present in the code. In the main branch the
$idURLs now point to the dev enviroment, as this environment tracks main anyway. The idea is that these URLs switching to the production ones will be a step during the promotion to the staging environment. Currently this is done "secretly" with a shell script in the docker start-up instance, but as the number of schemas grows, I think it makes more sense to have this be explicit and transparent. What you see is what you get.Follow-up PRs:
SchemBaseonInplaceVolumesResultupdate-schemato also check and dump that schemaupdate-schemato take a--releaseflag$idto use the production URLThen, additional schemas can be easily dumped. They will all go into the
schemas/directory, and the contents of this directory will mirror what's on the Radix instance.Effectively that will accomplish schema versioning as well.