(I wrote a reply earlier and sent it, but it appears to have disappeared into /dev/null. Apologies if it comes through at some later date.)
It seems adding a multiple kwarg and retrofitting it onto the existing FileField might not be the best idea. It might cause confusion with existing FileField APIs like size and name which don't make sense with multiple files. We could add a MultiFileField that had a files attribute, which returns a list of individual objects analogous to a single FileField? I guess that MultiFileField could be hidden between a 'multiple' keyword argument, but I'm not sure a migration from true to false would be possible which could also be confusing. On 31 Aug 2017 17:31, "Johannes Hoppe" <i...@johanneshoppe.com> wrote: I tried to exclude my personal opinion and preference from the ticket description, to have an open discussion. So here goes my personal opinion: It seems odd to me that the FileField is limited to 100 characters. I could not find any reference to why the field was limited in the first place. Furthermore I do not know of any file system with a 100 char limitation nor are URLs limited to only 100 chars. Therefore I would suggest basing the FileField upon the TextField. I would recommend splitting the issue tho. I would first add support form multiple files to form. This is a nice feature in itself and requires little work and good documentation. I would presume that such a feature would spawn a larger discussion on how to store those files. As multiple model instances? As an Array in Postgres? As CSV or JSON in a TextField? I think we can figure this out later or not at all if we don't come to a conclusion. I would love to work on that. I do maintain [django-s3file](https:// github.com/codingjoe/django-s3file/) and [django-stdimage](https:// github.com/codingjoe/django-stdimage/) and have some experience with custom the FileInput and FileField. Let me know if I can be of any help. Cheers -joe On Thursday, August 31, 2017 at 6:30:37 PM UTC+2, Johannes Hoppe wrote: > > Hi there! > > I already created a ticket regarding this matter, but I think this thicket > requires some discussion prior to crafting a solution. > https://code.djangoproject.com/ticket/28554 > > The django.db.models.FileField currently allows only to store a single > file URL. > This behavior seems outdated considering that input[type=file] supports a > multiple attribute, which is supported by all major Browsers. > See: https://www.w3schools.com/tags/att_input_multiple.asp > > I would suggest to have a similar attribute on the database field itself, > as well as on the form field and widget. > > The major point for discussion would be how to store the data. The easiest > would be to coma separate the paths in a single char field. The major > concern here would be the lack of atomicity. For databases like Postgres I > would be sensical to use the ArrayField as an underlying structure. Another > way for serialisation would be the use of JSONs in a char field. > > All solutions based on a text or char field have an issue related to the > compatibility with the current FileField which is limited to 100 > characters. The type would need to be migrated to a text type or the length > would need to be increased. The latter options bares the question to which > point. > > Another approach would be to defer the storage issue and only provide > support for multiple files on form level. > This would mean to add a multiple attribute to the form field and widget. > Users would be able to create forms with multiple files in a single field > and handle storage according to their preference. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/ msgid/django-developers/2b9bb49f-1cbc-4ea6-94df-774dfad43114%40googlegroups. com <https://groups.google.com/d/msgid/django-developers/2b9bb49f-1cbc-4ea6-94df-774dfad43114%40googlegroups.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJPrZZDJHhXpGKi9nbWA6RKnZBfxnHP1GFnt0Bf1HhFjmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
