#8918 closed New feature (fixed)
FileField upload_to should not be required for custom backends
| Reported by: | Leah Culver | Owned by: | nobody |
|---|---|---|---|
| Component: | File uploads/storage | Version: | dev |
| Severity: | Normal | Keywords: | FileField, files, upload, S3, upload_to |
| Cc: | physicsnick@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | yes | UI/UX: | no |
Description
For some file storage backends, the upload_to could be unnecessary. For example, I have an S3 backend and don't need any keys or prefixes for my files.
Currently an error is thrown if upload_to is missing or empty: "file": FileFields require an "upload_to" attribute.
Could upload_to be optional if the storage backend is custom?
Attachments (2)
Change History (22)
comment:1 by , 16 years ago
| Component: | Uncategorized → File uploads/storage |
|---|
comment:2 by , 16 years ago
comment:3 by , 16 years ago
| Version: | → SVN |
|---|
comment:4 by , 16 years ago
| milestone: | → 1.1 |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
There probably needs to be some flag you can set on the storage backend to indicate weather upload_to is required or not.
comment:5 by , 16 years ago
| Has patch: | set |
|---|
upload_to can be optional - all infrastructure is here, actually only check in validation.py makes it required.
comment:6 by , 16 years ago
| milestone: | 1.1 → 1.2 |
|---|
Punting from 1.1: this is annoying, but there's an easy workaround (just set upload_to = "dummy" or something).
comment:7 by , 15 years ago
| Cc: | added |
|---|
comment:8 by , 15 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:9 by , 15 years ago
| Triage Stage: | Ready for checkin → Design decision needed |
|---|
Bumping this off the "ready for checkin" stage following discussion with Jacob of some issues with the proposed solution.
In a nutshell, making upload_to optional makes code portability difficult; application code shouldn't differ based on the (deployment-specific) storage backend in use.
comment:11 by , 14 years ago
I'm not sure if Django should stop the user from doing this, but dedicating an entire bucket to a FileField seems like a bad idea. Setting upload_to to any string creates a pseudo-folder on Amazon S3 at no cost except for extra characters in the URL.
comment:12 by , 14 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:13 by , 12 years ago
| Triage Stage: | Design decision needed → Accepted |
|---|
Despite the portability issues, I still think upload_to should be optional.
comment:14 by , 11 years ago
| Easy pickings: | set |
|---|---|
| Patch needs improvement: | set |
Patch needs to be updated to apply cleanly and the change should be mentioned in the release notes (docs/releases/1.7.txt). These changes should be suitable for a first-time committer.
by , 11 years ago
| Attachment: | FileField_upload_to_optional.diff added |
|---|
The patch for master (1.7), making the upload_to optional
comment:15 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
In a strange twist, if you define a function for upload_to, the function can return the empty string. This should at least be documented? If the function returns None the filename is "Nonefilename.txt"... heh.