-
Notifications
You must be signed in to change notification settings - Fork 4.1k
feat: removing get_storage_class from COURSE_METADATA_EXPORT_STORAGE #36761
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
Open
dwong2708
wants to merge
3
commits into
openedx:master
Choose a base branch
from
dwong2708:dwong/updgrade-django-5-get-storages
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
""" Utility functions related to django storages """ | ||
|
||
from django.conf import settings | ||
from django.core.files.storage import default_storage, storages | ||
from django.utils.module_loading import import_string | ||
|
||
|
||
def resolve_storage_backend(storage_key, options=None): | ||
dwong2708 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
""" | ||
Configures and returns a Django `Storage` instance, compatible with both Django 4 and Django 5. | ||
|
||
Main goal: | ||
Deprecate the use of `django.core.files.storage.get_storage_class`. | ||
How: | ||
Replace `get_storage_class` with direct configuration logic, | ||
ensuring backward compatibility with both Django 4 and Django 5 storage settings. | ||
Returns: | ||
An instance of the configured storage backend. | ||
Raises: | ||
ImportError: If the specified storage class cannot be imported. | ||
""" | ||
|
||
storage_path = getattr(settings, storage_key, None) | ||
storages_config = getattr(settings, 'STORAGES', {}) | ||
|
||
if options is None: | ||
options = {} | ||
|
||
if storage_key == "default": | ||
# Use case 1: Default storage | ||
# Works consistently across Django 4.2 and 5.x | ||
# In Django 4.2 and above, `default_storage` uses | ||
# either `DEFAULT_FILE_STORAGE` or `STORAGES['default']`. | ||
return default_storage | ||
|
||
if storage_key in storages_config: | ||
# Use case 2: STORAGES is defined | ||
# If STORAGES is present, we retrieve it through the storages API | ||
# settings.py must define STORAGES like: | ||
# STORAGES = { | ||
# "default": {"BACKEND": "...", "OPTIONS": {...}}, | ||
# "custom": {"BACKEND": "...", "OPTIONS": {...}}, | ||
# } | ||
# See: https://docs.djangoproject.com/en/5.2/ref/settings/#std-setting-STORAGES | ||
return storages[storage_key] | ||
|
||
if not storage_path: | ||
# If no storage settings are defined anywhere, use the default storage | ||
return default_storage | ||
|
||
# Fallback to import the storage_path manually | ||
StorageClass = import_string(storage_path) | ||
return StorageClass(**options) |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
nit: Consider renaming 'COURSE_METADATA_EXPORT_STORAGE' to lowercase (e.g., 'course_metadata_export_storage') for consistency with other keys in STORAGES, which are conventionally lowercase.
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.
Got it, thanks for your feedback. I'm concerned about this because the current settings key, "COURSE_METADATA_EXPORT_STORAGE", is in uppercase. For that reason, I have a question: how will the transition to migrate these changes work? Will it be merged before the settings are migrated to STORAGES, or can we assume that the STORAGES settings will already exist?
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.
Yes, your concern is valid, so let’s keep the key as-is for now. There isn’t a finalized discussion yet on how the migration to the new STORAGES setting will be handled. At this stage, our focus is on updating deprecated methods for Django 4.2 and ensuring the code remains compatible with future versions like Django 5.x.
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.
Just to clarify, I was referring to the future STORAGES key, e.g.,
STORAGES = {"course_metadata_export_storage": "something"}
—not the existing
settings.COURSE_METADATA_EXPORT_STORAGE
. I mixed up the two earlier :) but for now no change require since we have no STORAGES plan yet.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.
Got it, thank you. Here are some ideas on how we could handle the migration:
Case 1:
Stage 1 (no breaking change): Migrate get_storage_class (this PR is an example) and merge it.
Stage 2 (breaking change): Migrate storage settings to the new convention, e.g., STORAGES = {}. and decide if we use lower or upper case in the key.
Stage 3: Ready to migrate to Django 5.
Case 2:
Stage 1 (no breaking change): Migrate get_storage_class (this PR is an example) and merge it.
Stage 2: Ready to migrate to Django 5 because the STORAGES settings is not required
Stage 3 (breaking change): Gradually migrate storage settings to the new convention, e.g., STORAGES = {}, in preparation for upgrading to Django 6.
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.
Stage 1 would be merging all these PRs as the initial step.
Stage 2 involves reaching out to the owning teams to get their input on the proposed migration plan. because it will effect the community also.
Looping in @feanil for visibility.