I see models as what defines the database ddl and and not a representation from a end users perspective. And I see the tight coupling between the 2 improper. Although in most cases the assumptions of representation and mapping of the 2 is mostly accepted, explicit is better than implicit. Of course we can have defaults that would work for most cases, but we need a way to override that. For me I rarely use the builtin generated widgets, I use restframework so all I'm interested in a model is for db definition in a highly customizable way.
I would opt for a db_length kwarg which can in turn be used for any field type eg. Timestamps On Wed, Jul 29, 2015 at 9:28 AM, Tim Graham <timogra...@gmail.com> wrote: > Ticket is https://code.djangoproject.com/ticket/14094 > > On Wednesday, July 29, 2015 at 1:41:01 AM UTC-4, Loïc Bistuer wrote: >> >> 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-develop...@googlegroups.com. >> > To post to this group, send email to django-d...@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/b6d01012-93bb-41b6-9065-c1d360e63b61%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b6d01012-93bb-41b6-9065-c1d360e63b61%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Aron Podrigal - '1000001', '1110010', '1101111', '1101110' '1010000', '1101111', '1100100', '1110010', '1101001', '1100111', '1100001', '1101100' P: '2b', '31', '33', '34', '37', '34', '35', '38', '36', '30', '39', '39' -- 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-yiFa0FeSc3of21MoKM_sFrfGkrk-6sHH11yXQDqB7Ldcg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
