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

Store file:values as list of dicts in Item properties #700

Merged
merged 2 commits into from
Jan 14, 2022

Conversation

duckontheweb
Copy link
Contributor

@duckontheweb duckontheweb commented Jan 6, 2022

Related Issue(s):

Description:

Converts List[MappingObject] to List[Dict[str, Any]] in the FileExtension.values setter. Also adds from_dict and to_dict methods to the MappingObject class.

PR Checklist:

  • Code is formatted (run pre-commit run --all-files)
  • Tests pass (run scripts/test)
  • Documentation has been updated to reflect changes, if applicable
  • This PR maintains or improves overall codebase code coverage.
  • Changes are added to the CHANGELOG. See the docs for information about adding to the changelog.

@duckontheweb duckontheweb added this to the 1.3.0 milestone Jan 6, 2022
@duckontheweb duckontheweb requested a review from lossyrob January 6, 2022 02:10
Copy link
Member

@gadomski gadomski left a comment

Choose a reason for hiding this comment

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

👍🏽 to this fix, I just ran into this myself.

A more general question: since we're essentially rolling our own (de)serialization library here, is it worth making an explicit class (or framework) for a (De)Serializable object? There can be other little classes deep in extensions (like this) that it could be nice to not have to re-implement this logic.

@duckontheweb
Copy link
Contributor Author

A more general question: since we're essentially rolling our own (de)serialization library here, is it worth making an explicit class (or framework) for a (De)Serializable object? There can be other little classes deep in extensions (like this) that it could be nice to not have to re-implement this logic.

Yeah, I think that would be useful. I started to play around with this a bit in #617, but haven't given it much attention lately. I think it would be useful to decouple the JSON serialization/deserialization from the links logic in STACObject so that we could re-use it in more places as you suggest.

@codecov-commenter
Copy link

codecov-commenter commented Jan 14, 2022

Codecov Report

Merging #700 (04d6d28) into main (f68cf81) will decrease coverage by 0.00%.
The diff coverage is 95.45%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #700      +/-   ##
==========================================
- Coverage   94.20%   94.20%   -0.01%     
==========================================
  Files          77       77              
  Lines       11120    11130      +10     
  Branches     1337     1340       +3     
==========================================
+ Hits        10476    10485       +9     
  Misses        466      466              
- Partials      178      179       +1     
Impacted Files Coverage Δ
pystac/extensions/file.py 91.53% <87.50%> (-0.47%) ⬇️
tests/extensions/test_file.py 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f68cf81...04d6d28. Read the comment docs.

@duckontheweb duckontheweb merged commit 5cff27d into stac-utils:main Jan 14, 2022
@duckontheweb duckontheweb deleted the fix/605-mapping-object branch January 14, 2022 15:06
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.

pystac.extensions.file.MappingObject doesn't work
3 participants