FieldFile with check if file exists, and don't raise errors by default

[Hersonls]

Many people ask and also has the need to verify that the file is sent to the server is really in its place.

This need arises because they are made unnecessary requests for lack of the file in media server and also for reasons of aesthetics, because the lack of image files or result in a different box with alt attribute, or result in a 404 not found.

The class FieldFile not give the developer the possibility to check if file exists and that is the developers create a method in a class model which will check if file exists on the media server or not.

I created a patch where it created a method for class FieldFile call is_exists which checks if the file exists. This method is valid for all inheritance of FieldFile class.

For example,

{% if object.file.is_exists %}<a href="{{ MEDIA_URL }}{{ object.file }}">download this file</a>{% endif %}
{% if object.image.is_exists %}<img src="{{ MEDIA_URL }}{{ object.image }}" alt="My image" />{% endif %}

[Hersonls]

Fix the patch

[dc]

If path is stored in database and actual file not exists then data is corrupted and better not create workarounds but fix it immediately.

Anyway os.path.exists will not work with non-local file systems better use self.storage.exists(self.name).

[Chris Beaven]

And "is_exists" seems ugly. Why not just "exists"?

But yeah, I'm dubious as whether this functionality is important enough to include in the api.

[Aymeric Augustin]

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.

[Simon Litchfield]

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.

[Tim Graham]

Hi, the correct procedure to reopen a ticket that's closed as wontfix is to start a discussion on the DevelopersMailingList.

In this case, I'm not sure how related your ideas are to the original ticket. Please try to include a demonstration of the behavior that's problematic. We have what sounds like a similar situation for djangoproject.com. The ​CorporateMember model has an ImageField for the logo, however, I haven't seen any crashes in Django when those files don't exist.