-
Notifications
You must be signed in to change notification settings - Fork 15
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
Refactor dmod.scheduler serialization and deserialization types #270
Refactor dmod.scheduler serialization and deserialization types #270
Conversation
Pre-pydantic versions of Job class used property setters. ``` @Property def prop(self) -> str: ... @prop.setter def prop(self, value: str): ... ``` Some properties with property setters mutatated state beyond just the associated property (e.g. reset `last_updated`). Pydantic will not allow you to create `@prop.setter`'s. Also, from a usage perspective, it not always clear if you can set a property without looking at documentation. To get around this, setter methods have been added to the Job class making it clear that you _can_ modify a properties value after instantiation. This also allows updating other instance internal state (i.e. `last_updated`). Likewise, to help us find and update portions of code that still set Job properties using prop setters, a DeprecationWarning is now thrown. To accomplish raising DeprecationWarnings, Job's `__setattr__` method was overridden. In short, there is a dict mapping of field names to associated setter methods that is called instead of `__setattr__`. As a side effect of this, setter methods must set field values through the instance `__dict__`. This avoids setter methods from raising a DeprecationWarning.
…e a classmethod and walk the mro
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes to Job in particular are pretty messy compared to what we were hoping for, but this will work. We might want to explore redesigning our core interfaces to separate serializable and business logic classes for modeling the same thing, but that can be something for the future.
Yeah, that is totally fair. At points I felt like I was using a hammer. I agree with your sentiment, I think circling back in the future is a good idea. Thanks! |
This PR refactors
dmod.scheduler
into compliance with ecosystem wide changes introduced in #256 to serialization and deserialization. See #239 for context.Additions
Removals
Changes
RsaKeyPair
now eagerly generates an RSA private key if one does not exist on disk or is not provided as a field.Testing
Screenshots
Notes
Todos
Checklist