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 information about requested downloads in a SQL database #1

Open
Florian-Katerndahl opened this issue Oct 17, 2024 · 3 comments
Open
Assignees
Labels
enhancement New feature or request

Comments

@Florian-Katerndahl
Copy link
Owner

Storing information about requested/failed/successful scene requests would allow the program to be used similarly to landsatlinks/FORCE's download suite.

Additionally, it may be possible to implement a background task which checks for availability while other threads already query the database for downloadable products.

@Florian-Katerndahl Florian-Katerndahl added the enhancement New feature or request label Oct 17, 2024
@Florian-Katerndahl Florian-Katerndahl self-assigned this Oct 17, 2024
@Florian-Katerndahl
Copy link
Owner Author

Using the sqlite3 module from the standard library should suffice and not introduce additional dependencies

Florian-Katerndahl added a commit that referenced this issue Oct 20, 2024
- The class PersistentMetadata addresses the proposed changes in #1,
  namely: Allow the program to store the metadata associated with
  landsat (and only landsat) scenes in addition to the download link
  and a flag indicating if the download was successfull
- The current implementation is likely not fully functional,
  correctness also not validated yet
@Florian-Katerndahl
Copy link
Owner Author

  • Check implementation proposal in standalone script
  • Assess storage space usage by database for multiple scenes when storing all metadata
  • Write at least some tests for the class method
  • integrate into cli_funcs::download

@Florian-Katerndahl
Copy link
Owner Author

Different satellites have different metadata, so if all is to be stored, there would need to be a case distinction. The easier and probably better approach would be to select a subset of attributes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant