Hi Aron, I'm +1 on addressing this, I often don't care about max_length, but I still want a terse form representation. In my projects I use a subclass of TextField that sets a TextInput wiget in its formfield() method. But that's not very elegant: it requires a custom field for a common use-case, and it's tightly coupled to Django forms (i.e. won't work with other form libraries and non-HTML forms).
Now how we address this depends on the meaning we want to give to models fields like CharField or TextField, more specifically whether the emphasis is on end user's perspective or on mapping 1:1 to database concepts. If we see CharField and TextField as respectively "short/single line field" and "long/multiline field" from a user's perspective, then it makes sense to lift the max_length requirement and use `db_type='TextField'` when max_length is None. However if we want to stay close to their database equivalents, then we could have a display hint on TextField (e.g. TextField(display_multiline=False)) and Field.formfield() would use that hint to provide a TextInput widget instead of a Textarea. Personally I'd much prefer option 1, it's significantly less verbose and more often than not I don't want a length constraint, especially considering that there is no performance penalty in doing so with all the databases that I care about. Also considering we want first class virtual field support (and plan on turning existing concrete fields into virtual fields) I don't think it's a big problem to break from the existing models.Field/db types mapping. Cheers, Loïc > On Jul 29, 2015, at 11:27, Podrigal, Aron <ar...@guaranteedplus.com> wrote: > > Hi, > > I am using postgresql and I prefer my VARCHAR columns not to have a length > limit. Is there any particular reason why max_length arg to fields is > required. If for compatibility with other database backends we can have some > sane default if it is None. > > > -- > 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CANJp-yjwzpk%2BN2%3D4WWbmj5zu2Gwu67G0Sme1f8xQa%2BKrzSQ2Rw%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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/EB67D8D3-1633-4CE7-9A7D-E22FA1EB4A47%40gmail.com. For more options, visit https://groups.google.com/d/optout.
