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 <[email protected]> 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. -- 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/663F6FA1-1D09-4A21-928A-836157386253%40gmail.com. For more options, visit https://groups.google.com/d/optout.
