Re: [Django] #11228: FieldFile with check if file exists.
Django
-------------------------------------+-------------------------------------
Reporter: hersonls | Owner: nobody
Type: New feature | Status: closed
Component: Database layer | Version: SVN
(models, ORM) | Resolution: wontfix
Severity: Normal | Triage Stage: Design
Keywords: | decision needed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* status: new => closed
* ui_ux: => 0
* resolution: => wontfix
* easy: => 0
Comment:
Like Chris, I doubt this would be generally useful. If you're losing
files, you're got bigger problems than broken links in your templates!
Furthermore, it's trivial to subclass !FileField to add this method if you
need it.
--
Ticket URL: <https://code.djangoproject.com/ticket/11228#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: hersonls | Owner: nobody
Type: New feature | Status: closed
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Design
| decision needed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: litchfield (added)
Comment:
Sorry to re-open, but the notion that an error is raised when attempting
to access attributes on a missing file is a wildly impractical default.
It assumes that "everyone at all times will have a full, up-to-date copy
of the media folder, that is exactly in sync with the database they're
running against".
If you're coding in a little bubble, eg pre-launch, against some bollocks
test data-- sure, lets raise errors and annoy ourselves. But in the "real
world" this is often/usually not the case and means you have to move
around massive media libraries and databases just to work on the site at
all, without resorting to temporarily commenting stuff out or hacking up a
custom field.
The default should be to return None, overridable through the field/model
definition (eg silent=False). And there should be an exists() method too,
why not? @aaugustin your presumption above "that you have bigger problems"
is totally irrelevant in many production scenarios.
--
Ticket URL: <https://code.djangoproject.com/ticket/11228#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: hersonls | Owner: nobody
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
| decision needed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by litchfield):
* status: closed => new
* resolution: wontfix =>
--
Ticket URL: <https://code.djangoproject.com/ticket/11228#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: hersonls | Owner: nobody
Cleanup/optimization |
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
| decision needed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
-------------------------------------+-------------------------------------
Changes (by litchfield):
* type: New feature => Cleanup/optimization
* easy: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/11228#comment:7>