Interesting, I love the discussion. I anticipated, that there are may different solutions and opinions regarding this topic. I will limit the implementation to `django.forms` for now and hope, that more people will voice their opinions regarding a model implementation once this becomes available to a broader audience.
Thanks everyone :) -- Johannes Hoppe Fon: +49 331 2812 9869 1 Fax: +49 331 2812 9869 9 www.johanneshoppe.com Lennéstr. 19 14469 Potsdam USt-IdNr.: DE284754038 On 2. Sep 2017, 10:37 +0200, Adam Johnson <[email protected]>, wrote: > I agree with Melvyn on the first point. I don't think Django should include > model fields that encourage denormalization by default (apart from JSONField > etc which are built into the DB). > > A forms.MultiFileField would make sense but to make storage easy it should > somehow translate into multiple rows in the DB. > > ArchiveField sounds a bit too specific for Django core, the most common case > for uploading multiple files would probably be to access them individually, > which it would prevent. > > > On 2 September 2017 at 08:30, Melvyn Sopacua <[email protected]> wrote: > > > I don't think a MultiFileField belongs in the model layer. > > > You're violating normalization principles making updates, > > > removals, counts etc, needlessly complex. > > > > > > From the ModelForm perspective, I can certainly appreciate > > > a multi file form field that I can tell to store each file as a new > > > model instance referencing 'app_label.modelname.filefieldname'. > > > > > > What could belong in the model layer is an ArchiveField, that > > > accepts multiple files, puts them in a single archive and stores > > > metadata (contents+count+whatever) in it's metadata_field > > > (similar approach as width and height for ImageField). > > > > > > > > > On Thu, Aug 31, 2017 at 7:29 PM, Tom Forbes <[email protected]> wrote: > > > > (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" <[email protected]> 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 [email protected]. > > > > To post to this group, send email to [email protected]. > > > > 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. > > > > > > > > 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 [email protected]. > > > > To post to this group, send email to [email protected]. > > > > 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. > > > > > > > > > > > > -- > > > Melvyn Sopacua > > > > > > -- > > > 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 [email protected]. > > > To post to this group, send email to [email protected]. > > > 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/CA%2Bgw1GWrv3pKTva9SxzycO%2Bc88EuLkKXkG%3DvDUdU2uoCHAt87g%40mail.gmail.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Adam > -- > You received this message because you are subscribed to a topic in the Google > Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/IU8L9Gc6LUI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > 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/CAMyDDM2jX7JjiF3T%2Br0jza_ThYa0_fdvftPMhLgnXE-PQ2aoCA%40mail.gmail.com. > 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 [email protected]. To post to this group, send email to [email protected]. 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/032d02ae-edf2-4d0f-8829-11bc99b336b8%40Spark. For more options, visit https://groups.google.com/d/optout.
