This discussion started because a user wants to leave off max_length for postgres, which allows the max_length to be omitted right? Is there anything wrong with `from django.contrib.postgres.fields import CharField`? The postgres specific CharField will allow max_length to be optional without interfering with other database backends, confusing the implementation of the standard CharField, or having to make seemingly difficult or arbitrary decisions on what a default max_length could be.
FWIW, I'm starting to come around to a default max_length of 128 for the base CharField, mainly for the reasons Shai has described (mysql max byte length for unique indexes, 128 characters being enough for the majority of CharField use-cases). There definitely are some issues with *requiring* users to arbitrarily define a max_length without having knowledge of all the ways that 255 may be a problem across backends, or understanding why 255 is even the theoretical max. If we were to consider this, I'd err on the side of changing CharField to default to max_length=128 rather than providing a new type. Cheers On Monday, 29 February 2016 06:07:04 UTC+11, Luke Plant wrote: > > Regarding custom sentinels for values vs custom sentinels for missing > values: > > The added complication in this case is migrations, and migrations that > support multiple Django versions, as is common in 3rd party apps. I haven't > thought through the implications, but it is vital to do so, because getting > it wrong can seriously hurt the adoption of a feature, and even the > adoption of a new version of Django. > > It may not be an option to say "for compatibility generate migrations > using the lowest supported Django versions", because sometimes old Django > versions have bugs that prevent migration generation. > > We also need to consider the potential need for several different sentinel > values e.g. "unlimited" vs "database defined max length". > > Luke > > On 28 February 2016 14:38:40 GMT+00:00, "Loïc Bistuer" < > loic.b...@gmail.com <javascript:>> wrote: >> >> There is a precedent to this (although it seems to happen at startup time >> rather than save time), we loop through all the connections and check that >> max_length has a value supported by their backend: >> https://github.com/django/django/blob/master/django/db/backends/mysql/validation.py. >> >> I don’t think we need to create a new sentinel value to mean “unlimited” >> when `max_length=None` works well semantically, if we want to keep the >> `max_length` value explicit we can just use `NOT_PROVIDED` as the kwarg >> default value. It is backwards compatible since `max_length=None` currently >> issues an error. >> >> Regarding the switch to a default value of 120 or so, I don’t have a strong >> opinion against it, but I think it’s an orthogonal problem to supporting >> unlimited varchar on backends that can handle it. >> >> On Feb 28, 2016, at 6:50 PM, Florian Apolloner <f.apo...@gmail.com >> <javascript:>> wrote: >>> >>> I do not see how blowing up on save is a good idea (especially not if we >>> ran model validation before). We do not do that for MySQL (at least not if >>> your project is configured properly, leaving issues with utf8mb4 out for >>> now) since our model form validation is able to use the supplied max_length >>> to inform the user that the data is invalid __before__ save. >>> >> > -- > Sent from my phone > -- 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/02818c88-5b1c-41ee-be86-b48df0580a24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
