Fix #206 -- Overwrite variations by defaults

[codingjoe]

We now overwrite files by default when a new files gets uploaded.
This fixes an issue, where someone might upload a file with the
same name twice the first initial variations get not replaced
with a version of the newer file.
It happens in the least IO consuming way. The rendervariations
management command still behaves as before where variations are
not replaced by default.

[codingjoe]

@caspervk would you do me the honor of a quick review?

[codecov]

Codecov Report

Merging #213 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #213   +/-   ##
=======================================
  Coverage   98.85%   98.85%           
=======================================
  Files           3        3           
  Lines          87       87           
=======================================
  Hits           86       86           
  Misses          1        1

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ba36e6c...9920fd9. Read the comment docs.

[caspervk]

@codingjoe Thank you! I only have a few comments:

1. File is overwritten if not file_overwrite? Is this intended?
2. Striving for as few IOs as possible, but doing both storage.exists() and storage.delete()? Is it possible to just storage.open()/.save() directly without checking if the file already exists first? I'm honestly not sure how storages work in Django, but in regular Python, doing with open("foo", "w") as f; f.write(..) will save/overwrite to foo regardless of whether the file already exists or not, achieving the desired behavior in a single IO. If storage.save() behaves in the same way, the check and deletion could possibly be refactored away?

[caspervk]

@codingjoe Actually, I just remembered that at least S3Boto3Storage from Django-storages behaves in this sane way. Simply deleting the checks and doing storage.save() (as done here) works -- no need to check and delete the file first!

[codingjoe]

@codingjoe Actually, I just remembered that at least S3Boto3Storage from Django-storages behaves in this sane way. Simply deleting the checks and doing storage.save() (as done here) works -- no need to check and delete the file first!

Yes, then again we do have to support more than one storage backend. Also, this is only true, if you have the overwrite-flag at its default True which many people don't. I though about just calling delete, sadly the Storage class definition does not define a common exception that should be raised. Therefore, any backend might throw a variety of different exceptions. It's not ideal, but I don't see a reliable way to improve it.

[caspervk]

I commented here: #206 (comment).

Can't wait to have this merged!

[codingjoe]

Released in 5.0.1