On Saturday 27 February 2016 23:57:19 Florian Apolloner wrote: > Hi Shai, > > On Saturday, February 27, 2016 at 4:44:18 PM UTC+1, Shai Berger wrote: > > I think this is why we should be a little more cautious and go for 128 or > > 100, > > rather than "the current maximum all-backend-compatible value". > > Which somewhat speaks for my point, cause we do not know if the next > backend will need less than 100 chars (But I do agree that this is not > likely). Tough I think that 100 (or 191 for matter) is a ridiculously low > limit.
No, it isn't, if you think of the default char-field as a one-liner; even in code, we don't like lines longer than 120 chars... and the default should be friendly to backends with odd limitations, like Oracle's 8KB limitation on the sum of inline fields in a row (which means the "max acceptable for oracle charfield" value, which takes half of that, is a horrible default). > In that sense, allowing max_length=None is probably the safest > solution -- even though we do not know when database backends will crash on > this, but we do not know this for text fields either currently. > The SQL Standard has many deficiencies, but it's the best resource to work against in this regard; and the only unlimited-length character field it supports are LOBs (see [1]). While PG treats LOBs and char-fields the same, it is the exception rather than the rule, and I suspect it is part of the reason for why, when push comes to shove, it does not perform as well as the proprietary databases (don't get me wrong: I prefer it to any of them -- but it's a bit like comparing Python with C; you pay for expressivity with performance). > > > That all said, if it were for me I'd deprecate CharField and only > > > support TextField and give it an optional max_length (and a way to > > > switch between TextArea and LineEdit for UI) -- but that is probably > > > just because on Postgres there is no fundamental difference between them. > > > From an enduser perspective, it is all text, the only difference is a > > > constraint in length, > > > > No, that's not the only difference. There's also an understanding that > > CharField's are one-liners, that is, there is an implicit limitation > > (usually > > only enforced by UI) that newlines are not allowed in the text. > > This is a leaky abstraction at best in my opinion. The "understanding" is > mostly coined by the documentation in the sense that it mentions <textarea> > for TextField and <input> for CharField. So it is kind of illogical to not > allow a max_length on TextField. I am not opposed to a max_length on TextField. I am opposed to setting the default string field in Django to an unlimited-length one. > Even with model.full_clean there is no > restriction aside from the length, in that sense a CharField behaves > completely the same as TextField (database issues with index lengths etc > excluded). Databse issues with LOBs are plenty. PG has spoiled you :) Other databases do not do functional dependencies properly, and as a result, when you include a LOB in a grouping or uniqune query you get either database errors (Oracle) or terrible performance (everyone else except PG, AFAIK). > > For example, I don't > > > think there are many CharField's whose contents are interpreted as > > markup. > > Maybe, maybe not, I do not see how this makes a difference here though. > (Same goes for Regex validation). > The point was: They are regarded as different data types, have different operations etc. > > In a user perspective, these are really different data types. > > Which can be dangerous on it's own, I'd have to check, but I am pretty sure > that nothing prevents the user from submitting newlines in a CharField. > I, too would be surprised if something does. Agreed on "leaky abstraction". > > I find your suggestion > > analogous to a suggestion to remove IntegerField, because "it's just a > > FloatField with a constraint on scale". > > I'd suggest a DecimalField cause I do not like FloatFields either, but yeah > ;) > > Do not get me wrong, I somewhat agree with everything you say (in the end I > think it is just a matter of taste) -- but I also think that explicit is > better than implicit. I tend to agree with original posters in this thread -- explicit here just means "unnecessary room for error". Django is opinionated about database design, and I think we stand to gain by expressing on opinion about the default length of a "regular, one-line charfield". > From a security point of view, I agree that length > validation should be done whenever it makes sense [which is basically > always, there is no point in allowing to post the maximum length of a > TextField, especially not if it contains markup which you have to render > again ;)], so a CharField with a default max_length seems like a good idea. > On the other hand I think that it will make the distinction for new users > even harder. Assume we change the CharField to have a default max_length, > the first (and probably only thing) users will notice is that CharField is > single line. I am somewhat reading #django 24/7 and can tell you that no > matter how much we write in the docs, users are reading them less and less. > So for all practical purposes a single field allowing for all of that is > imo the best abstraction. > Now, *that* is a leaky abstraction -- good luck hiding all the behavior differences between limited-length and unlimited-length charfields, on any backend but PG. Shai.
