#26562: Introduce Storage and FileSystemStorage alternate save behaviour
-------------------------------------+-------------------------------------
     Reporter:  freshquiz            |                    Owner:  nobody
         Type:  New feature          |                   Status:  new
    Component:  File                 |                  Version:  master
  uploads/storage                    |
     Severity:  Normal               |               Resolution:
     Keywords:  file FileField       |             Triage Stage:  Accepted
  storage overwrite filepath         |
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by freshquiz):

 Tim, are you referring to changing the default behaviour of `Storage`?
 If so, I never said to make this alternative behaviour default. I
 suggested the current behaviour be kept default, but just to have this
 alternative behaviour as a configurable option.

 If you are saying this behaviour shouldn't exist in Django at all, I would
 like justification as to why, please.

 Your argument about allowing users to clobber existing files, it doesn't
 make sense to me.

 If you believe you need to be that protective, why does Django offer a
 `delete()` method on models?
 Why aren't you overly protective of existing database records?
 The answer is, because it makes no sense to natively not allow the ability
 for database records to be deleted.
 Why should countless Django client devs have to duplicate the behaviour
 themselves, just because you think they are too careless to be able to
 prevent misuse?

 That might be a bit of an extreme analogy, but the ability to make raw
 queries in Django, is less extreme, but still a valid analogy.
 Yes it has the potential to be more risky than using model queries in the
 traditional way, but you still enable the clients to be able to utilise it
 if they need it (albeit with a lot of warnings).
 Why not the same here?

 I understand your (and other core devs') reservations, but I don't agree
 that they are justification for not allowing the behaviour to exist
 natively, at all.

--
Ticket URL: <https://code.djangoproject.com/ticket/26562#comment:6>
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/067.e3a849e13922da001ae9bf252a9f9def%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to