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-43769: Improve Pydantic support for sphgeom.Region and Timespan #997
Conversation
1dd159a
to
a803022
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #997 +/- ##
==========================================
- Coverage 88.98% 88.97% -0.01%
==========================================
Files 344 344
Lines 44141 44199 +58
Branches 9084 9100 +16
==========================================
+ Hits 39278 39326 +48
- Misses 3549 3556 +7
- Partials 1314 1317 +3 ☔ View full report in Codecov by Sentry. |
c1cfd21
to
ce88844
Compare
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.
Looks alright to me. I suggested a possible implementation that doesn't require resorting to pydantic core. Whether this is easier to understand is a matter of taste, so take it or leave it. 🤷
adapter.validate_json({}) | ||
with self.assertRaises(ValueError): | ||
adapter.validate_json((b"this is not a region").hex()) | ||
|
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.
Might be worth adding a test for "a string, but not a hex string." (Pretty sure it will pass already.)
Also in the future feel free to delegate any little tickets like this to me, I'm sure you have much bigger fish to fry :D |
Pydantic's symbols (especially Field) often aren't obviously from Pydantic on their own, so I think it's one of the cases where 'import pydantic' is better than 'from pydantic import <stuff>', especially when '<stuff>' is long, as it is about to become here.
This cleaned up some special-casing in DimensionRecord serialization, but it required some other special-casing to be replaced, for two primary reasons: - The 'direct' deserialization methods (which we *may* not even need) is hashing entire proto-records in its cache system, while it should just be using required-dimension-value tuples. - I haven't tried to replace the special-casing for 'region' and 'hash' (this one really bakes in some bad assumptions about the concrete universe!). I have thoughts for addressing both issues but I think they're more than I want to do on this branch.
This requires making Timespan.nsec public, which is only slightly unfortunate; we can declare it frozen to maintain immutability, and we couldn't realistically change the implementation in the future given that we've already exposed that in how it's serialized. This obsoletes the previous commit on this branch that used pydantic_core, but I'm keeping that version in the commit history in case it's meaningfully more efficient in validation or memory use (I suspect it's slightly more efficient, but not enough to matter).
Co-authored-by: David H. Irving <david.irving@noirlab.edu>
Co-authored-by: David H. Irving <david.irving@noirlab.edu>
d9e12e9
to
ad25039
Compare
Checklist
doc/changes
configs/old_dimensions