As upload_to could be used to completely change the name of the uploaded
file it should, in my opinion, be considered part of the filename.
Or should at the very least be mentioned in the docs for clarity.
If upload_to is defined, setting unique=True does effectively nothing
right now. The file is passed on and a unique filename is generated (->The
default behavior of adding an underscore followed by seven random
characters) instead of raising an error.
--
Ticket URL: <https://code.djangoproject.com/ticket/34237>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> #27188 added support for setting unique=True for the FileField.
> This does not seem to take the upload_to argument into account.
>
> As upload_to could be used to completely change the name of the uploaded
> file it should, in my opinion, be considered part of the filename.
> Or should at the very least be mentioned in the docs for clarity.
>
> If upload_to is defined, setting unique=True does effectively nothing
> right now. The file is passed on and a unique filename is generated
> (->The default behavior of adding an underscore followed by seven random
> characters) instead of raising an error.
New description:
#27188 added support for setting unique=True to the FileField.
This does not seem to take the upload_to argument into account.
As upload_to could be used to completely change the name of the uploaded
file it should, in my opinion, be considered part of the filename.
Or should at the very least be mentioned in the docs for clarity.
If upload_to is defined, setting unique=True does effectively nothing
right now. The file is passed on and a unique filename is generated (->The
default behavior of adding an underscore followed by seven random
characters) instead of raising an error.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34237#comment:1>
* status: new => closed
* resolution: => invalid
Comment:
Replying to [ticket:34237 0x4A-0x41-0x4B]:
> #27188 added support for setting unique=True to the FileField.
> This does not seem to take the upload_to argument into account.
As far as I'm aware, `upload_to` directory is concatenated with the `name`
and accounted for by an unique constraint.
> As upload_to could be used to completely change the name of the uploaded
file it should, in my opinion, be considered part of the filename.
> Or should at the very least be mentioned in the docs for clarity.
>
> If upload_to is defined, setting unique=True does effectively nothing
right now.
That's not true. `unique=True` only means that a database-level constraint
is created.
> The file is passed on and a unique filename is generated (->The default
behavior of adding an underscore followed by seven random characters)
instead of raising an error.
It depends on the implementation of `storage.generate_filename()`. The
database constraint is the last frontier where uniqueness is protected.
--
Ticket URL: <https://code.djangoproject.com/ticket/34237#comment:2>
* status: closed => new
* resolution: invalid =>
Comment:
Replying to [comment:2 Mariusz Felisiak]:
> As far as I'm aware, `upload_to` directory is concatenated with the
`name` and accounted for by an unique constraint.
This is strictly taken from the documentation (i have not yet looked into
the source to back this up). If you define a custom upload_to callback, it
will be passed on directly to the storage's save method (as mentioned in
the
[https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.FileField.upload_to
documentation]).
> That's not true. `unique=True` only means that a database-level
constraint is created.
Yep, that's true, sorry for the mistake on my part.
> It depends on the implementation of `storage.generate_filename()`. The
database constraint is the last frontier where uniqueness is protected.
Well, what's the point of upload_to then? Why would i ever use the
FileField's upload_to, if i can use the storage's generate_filename
method?
This puts up a barrier for anyone trying to enforce a purely unique set of
file entries. The documentation for this is, if nothing else, misleading:
> This attribute provides a way of setting the upload directory and file
name ...
[https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.FileField.upload_to
Source]
As its clearly NOT used to set the filename if the storage can (and will)
completely disregard it.
--
Ticket URL: <https://code.djangoproject.com/ticket/34237#comment:3>
* status: new => closed
* resolution: => invalid
Comment:
> Well, what's the point of upload_to then? Why would i ever use the
FileField's upload_to, if i can use the storage's generate_filename
method?
If you prefer to write and use a custom storage, please do. The
`upload_to` option is intended for most of users who would like to change
only the directory, not other storage mechanisms.
> This puts up a barrier for anyone trying to enforce a purely unique set
of file entries. The documentation for this is, if nothing else,
misleading:
> > This attribute provides a way of setting the upload directory and file
name ...
[https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.FileField.upload_to
Source]
> As its clearly NOT used to set the filename if the storage can (and
will) completely disregard it.
Built-in storage uses `upload_to`. I'm not sure what you're proposing, do
you want to document that 3rd-party storages can ignore `upload_to`? TBH,
they can do almost anything, that's how custom implementation works, I see
no point in documenting this. Feel-free to propose a docs clarification,
however I'm skeptical.
For me this ticket is still "invalid".
--
Ticket URL: <https://code.djangoproject.com/ticket/34237#comment:4>