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

fix #516: thumbnail_cleanup command for S3 and different source storages #562

Merged
merged 5 commits into from
Jul 27, 2024

Conversation

PetrDlouhy
Copy link
Contributor

@PetrDlouhy PetrDlouhy commented Dec 4, 2020

I was able to make partial fix for #516.

It enables thumbnail_cleanup to work correctly with S3 stoarges and works with different source and destination storage.

The default source storage is now set to DEFAULT_FILE_STORAGE (which is probably better choice in case when the source and destination storages differ), and can be changed by the management command --source-storage parameter.
It also adds check for the source storage hash, and if the hashes differ, it only prints warning, but take no action.

May be we could detect all possible storages and compare their hashes with the source.storage_hash value. But I am not sure, if I can load all storage options from settings. The situation would be much easier, if the storage classpath string is stored directly in the Source objects.

Also this change doesn't cover cases, when user wants to change the source storages. In such cases it might be useful either to change the source hash or to delete the thumbnail reference based on users requirements.

@DmytroLitvinov
Copy link

Hi there.
We have integrated AWS S3 storage also and struggled with the same issue.
Is any help needed for merging that PR? I am open to help here.

@jrief
Copy link
Collaborator

jrief commented Dec 14, 2022

Is there a way to test this?
Since that might be impossible, at least, I'd like to see some documentation on this topic.

@PetrDlouhy
Copy link
Contributor Author

@jrief Maybe at least some testing could be added.
When I would make the tests, I would like to establish coverage collection first. Do you agree with the choice of Codecov?

@PetrDlouhy
Copy link
Contributor Author

With introduction of Django 4.2+ storages, this problem is easier to solve.

I have rewritten this, so that it autodetects the correct storage based on the Source.storage_hash from the STORAGES available. There is no need to ask user to specify source storage, also the storage can change for each Source object.

For this reason the support of older Django versions needs to be dropped, but they out of support anyway.

This PR contains commits from other PRs (#638, #635) which are meant to be merged first. I have improved tests for this new functionality.

@jrief jrief merged commit 8a39592 into SmileyChris:master Jul 27, 2024
5 checks passed
@jrief
Copy link
Collaborator

jrief commented Jul 28, 2024

Thanks @PetrDlouhy , I just released version 2.9.0.
Please check, since I just created that release.

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.

3 participants