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

Refactor dmod.scheduler serialization and deserialization types #270

Merged

Conversation

aaraney
Copy link
Member

@aaraney aaraney commented Feb 6, 2023

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

  • PR has an informative and human-readable title
  • Changes are limited to a single goal (no scope creep)
  • Code can be automatically merged (no conflicts)
  • Code follows project standards (link if applicable)
  • Passes all existing automated tests
  • Any change in functionality is tested
  • New functions are documented (with a description, list of inputs, and expected output)
  • Placeholder code is flagged / future todos are captured in comments
  • Visually tested in supported browsers and devices (see checklist below 👇)
  • Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
  • Reviewers requested with the Reviewers tool ➡️

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.
Copy link
Contributor

@robertbartel robertbartel left a 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.

@robertbartel robertbartel merged commit 6d5c4ca into NOAA-OWP:pydantic-serializable Feb 22, 2023
@aaraney
Copy link
Member Author

aaraney commented Feb 22, 2023

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!

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.

2 participants