Skip to content

Download file type refactor and semantic versioning#274

Merged
ChrisJohnNOAA merged 4 commits intoERDDAP:mainfrom
ChrisJohnNOAA:download_type_refactor
Apr 24, 2025
Merged

Download file type refactor and semantic versioning#274
ChrisJohnNOAA merged 4 commits intoERDDAP:mainfrom
ChrisJohnNOAA:download_type_refactor

Conversation

@ChrisJohnNOAA
Copy link
Contributor

Description

This refactors the code for file downloads to make it easier to add a new file type to ERDDAP. Because the file types were the primary space that ERDDAP internally used the version, I also updated the code to support semantic versioning while I was modifying it all.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

  • New feature (non-breaking change which adds functionality)

Checklist before requesting a review

  • I have performed a self-review of my code
  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

@clifford-harms
Copy link

This is a big deal, much needed change in my opinion. This is one of the key elements (along with similar work for the dataset ingest) that will allow extending ERDDAP formats without fiddling with Erddap.java. I like the cache integration, migration of existing outputs to the new interfaces, and encapsulation of request info (DapRequestInfo), so no more 6+ argument methods. I may have missed it (large PR), does FileTypeClass have everything that is needed to expose the output format in the existing GUI?

@ChrisJohnNOAA
Copy link
Contributor Author

This is a big deal, much needed change in my opinion. This is one of the key elements (along with similar work for the dataset ingest) that will allow extending ERDDAP formats without fiddling with Erddap.java. I like the cache integration, migration of existing outputs to the new interfaces, and encapsulation of request info (DapRequestInfo), so no more 6+ argument methods. I may have missed it (large PR), does FileTypeClass have everything that is needed to expose the output format in the existing GUI?

Thanks!

That is the goal of FileTypeClass, however the localized descriptions were complicated. The way the annotation information is used is through a helper in EDD: EDDFileTypeInfo. This also hides from the rest of the code that for localized descriptions we instantiate the class and get the localized text that way.

A new filetype needs to be implement FileTypeInterface and have the FileTypeClass annotation.

@ChrisJohnNOAA ChrisJohnNOAA merged commit 45ec1da into ERDDAP:main Apr 24, 2025
1 check passed
@ChrisJohnNOAA ChrisJohnNOAA deleted the download_type_refactor branch April 24, 2025 17: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.

2 participants