The reason for having a max_length set to None, is because that's what I want for my database columns to be in Postgres, and for MySQL I don't care about the length too, I always choose varchar(255) just for because it is required for the database backend. And for validation of the max length, I would argue that just like validating the max I want to validate the min. In short, I want to have more control on my database schema.
And for your concern, there will be a MaxLengthValidator added to the validators to validate the users input does not exceed the database backends maximum length just like when you set max_length explicitly. Also you can manually provide a validator if your user input validation rule is to be less than the db maximum length. See [1]. The MaxLengthValidator should actually only be added if there isn't yet any MaxLengthValidator explicitly given. [1] https://github.com/django/django/blob/9a97f847109d377995a2312e3d569a3dad1da677/django/db/models/fields/__init__.py#L1102-L1109 On Mon, Sep 21, 2015 at 8:52 PM, Christophe Pettus <x...@thebuild.com> wrote: > > On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron" <ar...@guaranteedplus.com> > wrote: > > > Different schemas?? Schema will always be different for each database > backend according to its datatypes. > > It means if you specify a CharField without a length, you don't know how > many characters it can accept without error. That doesn't seem like > something we should make a change to accept. > > > I really don't understand what your concern is. > > The current behavior seems entirely reasonable, and I'm not sure I > understand what problems it is causing. Specifying a maximum length on a > CharField is not just a random habit; it should be done as a way of sanity > checking the value to a reasonable length. Sometimes, that's natural to > the data (there are no 50 character telephone numbers or 5000 character > email addresses), sometimes it's just a way of making sure that something > bad doesn't get into the database. > > -- > -- Christophe Pettus > x...@thebuild.com > > -- > 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/15D5715A-3EF5-4CC0-830C-8EB714424335%40thebuild.com > . > 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-yjm-wLsR4neSjM5q_-9d5LNOfDXUmnyAan1zB2emdR%3D_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
