#28200: Do not touch hash-designated files which already exist at the
destination
storage
-------------------------------------+-------------------------------------
Reporter: Michal | Owner: nobody
Krupa |
Type: | Status: new
Cleanup/optimization |
Component: | Version: 1.11
contrib.staticfiles | Keywords: staticfiles,
Severity: Normal | storage, remote
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
It seems a little silly that, even though local file copies are used to
prevent needing to fetch files from remote destinations, files still get
replaced even when they already exist.
In example, a remote storage implementation like S3 gets queried for the
file, the file gets removed, and then replaced. With the boto3 library,
this means touching the file initially (HEAD), a second request to DELETE
the file, and yet a third to PUT the new file. Since filenames for hashed
files are computed based on the contents of the files, this seems like an
unnecessary 3 requests for every time static assets get processed.
Since a matching hash provides file integrity verification, I propose that
the logic for copying hash-designated files be skipped all together.
PR Available here - https://github.com/django/django/pull/8496
--
Ticket URL: <https://code.djangoproject.com/ticket/28200>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/054.48080f9034a12c5a40356ecc8e4413d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
