Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DM-25985: Add saving and checking of per-manager versions #335

Merged
merged 4 commits into from Aug 3, 2020

Conversation

andy-slac
Copy link
Contributor

For each manager we now store its full name, version number, and schema
digest. Some control for that has been moved to a separate interface
which needs to be implemented by each manager class. Saved manager name
could be different from one specified in registry config due to
difference in module names.

Copy link
Member

@TallJimbo TallJimbo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, only minor comments.

One big-picture comment: why use multiple inheritance instead of just making all of the manager ABCs inherit from VersionedExtension? It looks like that's effectively required for all implementations anyway.


Notes
-----
The is no exact definition of digest format, any string should work.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: "The" -> "There"

-----
The is no exact definition of digest format, any string should work.
The only requirement for string contents is that it has to remain
stable over tim if schema does not change but it should produce
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: "tim" -> "time"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or Tim 😄


Returns
-------
digest : `str` or `None`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider making these bytes instead of str, to move the burden of something like base64 or hex encoding out of implementations of this class, and into something common (and also guarantee that some encoding like that is used)? I assume that essentially all of the time they'll start out as bytes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern here was that we need to save them in the database as strings because attribute table is a string -> string mapping. We could require bytes digests but then I'd need to convert them into string format (e.g. with hex encoding) when saving and convert back to bytes when reading. I decided to leave the choice for encoding to extension, besides there may be a case when digest can be produced as an actual human-readable string.

@andy-slac
Copy link
Contributor Author

andy-slac commented Aug 3, 2020

Re multiple inheritance - I was thinking that there may be some manager implementations that don't need version support (or may not even have database schema). Requiring those to implement versioning ABC looks like unnecessary burden. OTOH as you say all our current managers support versioning, so may be it will simplify things if we use versioning ABC as a base class for all of them, implementing that interface when version is not needed should be trivial task.

For each manager we now store its full name, version number, and schema
digest. Some control for that has been moved to a separate interface
which needs to be implemented by each manager class. Saved manager name
could be different from one specified in registry config due to
difference in module names.
@andy-slac andy-slac merged commit 49b7167 into master Aug 3, 2020
@timj timj deleted the tickets/DM-25985 branch February 16, 2024 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants