Making max_length argument optional

1332 views
Skip to first unread message

Podrigal, Aron

unread,
Jul 29, 2015, 12:27:59 AM7/29/15
to Django developers (Contributions to Django itself)

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.

Loïc Bistuer

unread,
Jul 29, 2015, 1:41:01 AM7/29/15
to django-d...@googlegroups.com
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.

Tim Graham

unread,
Jul 29, 2015, 9:28:50 AM7/29/15
to Django developers (Contributions to Django itself), loic.b...@gmail.com

Podrigal, Aron

unread,
Jul 29, 2015, 12:25:34 PM7/29/15
to Django developers (Contributions to Django itself), loic.b...@gmail.com
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


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'

Aymeric Augustin

unread,
Jul 30, 2015, 5:17:56 AM7/30/15
to django-d...@googlegroups.com, loic.b...@gmail.com
> Le 29 juil. 2015 à 18:25, Podrigal, Aron <ar...@guaranteedplus.com> a écrit :
>
> I see models as what defines the database ddl and and not a representation from a end users perspective.

Django models do a bit more than this: see the `validators` argument, EmailField, etc.
> And I see the tight coupling between the 2 improper.

I understand your perspective; it's a trade-off between purity and convenience and the optimal answer depends on each project.
> 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.

Please make sure your proposals also account for the various way Django can be and has been used :-)

--
Aymeric.

Podrigal, Aron

unread,
Sep 21, 2015, 12:15:16 AM9/21/15
to Django developers (Contributions to Django itself), loic.b...@gmail.com
Iv'e started to work on this ticket [1] today and here [2] is my work so far. I'd appreciate some feedback on the implementation.
There are a couple ways to handle the database type length. 

1) Separate types one with a length spec and one without (as mentioned by Ben Davis in the ticket)
2) Some interface to get the type length specs (the approach I took)

The second option more generic, and provides an interface for any type to specify a length or scale precision.

--
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.

For more options, visit https://groups.google.com/d/optout.

Paulo Maciel

unread,
Sep 21, 2015, 12:21:57 PM9/21/15
to Django developers (Contributions to Django itself)
+1 max_length optional

Tom Evans

unread,
Sep 21, 2015, 12:54:55 PM9/21/15
to django-d...@googlegroups.com
On Mon, Sep 21, 2015 at 5:21 PM, Paulo Maciel
<paulosou...@gmail.com> wrote:
> +1 max_length optional
>

I'm slightly worried from a DB point of view. Whilst blessed
PostgreSQL supports variable length fields seemingly without issues,
other DB engines (MySQL, for instance), have significant performance
issues using a TEXT field versus a VARCHAR field - particularly on
indexed fields, it must do a row read to retrieve data, rather than
use an indexed value.

Remember that VARCHAR columns can be fully indexed, whilst TEXT
columns can only have the first N (specified by user) characters
indexed, and reading the data will always require a row read, even if
the text is shorter than the indexed size.

In the ticket, it states that

"""
If I read the oracle docs correctly, specifying a length is mandatory
for VARCHAR2, and the maximum is 4000 bytes. For MySQL, it's 65K
bytes, for PostgreSQL and SQLite it's very large.
"""

For MySQL, it is 64k (65,535 bytes is *not* 65k!), and that is not the
whole story - 64k is the maximum record size - all your columns must
fit within that limit, not just one column in the record.

http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

I'm slightly concerned as a MySQL/MariaDB user that this will lead to
"reusable" apps that are not performant on MySQL. Given that we
(generally) let Django define the database tables based upon models,
it seems much more important that the definition is correct and high
performing in all supported backends than to avoid choosing what
database columns you require in the tables - after all, that is what
the TextField is for, to allow the programmer to specify "this is an
arbitrary length text field".

I'm all for DB engines that support arbitrary length varchar fields to
use that when you specify a TextField. I'm very not keen on having
MySQL represent the majority of char fields as TEXT because no-one
could be bothered to specify the appropriate length.

Cheers

Tom

Christophe Pettus

unread,
Sep 21, 2015, 2:46:42 PM9/21/15
to django-d...@googlegroups.com

On Sep 21, 2015, at 9:54 AM, 'Tom Evans' via Django developers (Contributions to Django itself) <django-d...@googlegroups.com> wrote:
> I'm slightly worried from a DB point of view.

I have to agree, even speaking as PostgreSQL geek. While VARCHAR and TEXT are implemented the same way in PostgreSQL, conceptually they're different things. I don't think the relatively modest benefit of having no default justifies the problems that result on other platforms.

--
-- Christophe Pettus
x...@thebuild.com

Podrigal, Aron

unread,
Sep 21, 2015, 5:49:44 PM9/21/15
to Django developers (Contributions to Django itself)
We're not talking about representing all CharFields as TEXT, it is about choosing a sane length as the default for the varchar datatype. So if you would not specify max_length, for MySQL it would be varchar(255), for oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and for PostgreSQL it would be just VARCHAR without a length.

I would like some comments / help for how to compute the size of the string in bytes for Oracle. unless we can opt for using a default length of 255 for all database backends besides postgres.

--
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.

For more options, visit https://groups.google.com/d/optout.

Christophe Pettus

unread,
Sep 21, 2015, 8:42:40 PM9/21/15
to django-d...@googlegroups.com

On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron" <ar...@guaranteedplus.com> wrote:

> We're not talking about representing all CharFields as TEXT, it is about choosing a sane length as the default for the varchar datatype.

But that means notably different schemas on different backends, for not an obvious gain. What's the benefit there?

Podrigal, Aron

unread,
Sep 21, 2015, 8:49:11 PM9/21/15
to Django developers (Contributions to Django itself)
Different schemas?? Schema will always be different for each database backend according to its datatypes. I really don't understand what your concern is. In any case your free to specify a max_length=N where it will be the same for all backends.

--
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.

For more options, visit https://groups.google.com/d/optout.

Christophe Pettus

unread,
Sep 21, 2015, 8:52:39 PM9/21/15
to django-d...@googlegroups.com

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.

Podrigal, Aron

unread,
Sep 21, 2015, 9:12:25 PM9/21/15
to Django developers (Contributions to Django itself)
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.

--
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.

For more options, visit https://groups.google.com/d/optout.

Christophe Pettus

unread,
Sep 21, 2015, 10:03:18 PM9/21/15
to django-d...@googlegroups.com

On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron" <ar...@guaranteedplus.com> wrote:

> 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.

Well, that's not a practice I think we need to go to great lengths to support. If you *really* *must* have a VARCHAR field without a length, you can always use a migration to strip it off.

Podrigal, Aron

unread,
Sep 21, 2015, 10:10:48 PM9/21/15
to Django developers (Contributions to Django itself)
There is actually another reason to not have to specify a max_length which was mentioned earlier, is because most of the time you don't care about that and is just tedious to have to specify that when you can get it to work without it. Default values has always been here for that reason.

--
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.

For more options, visit https://groups.google.com/d/optout.

Christophe Pettus

unread,
Sep 21, 2015, 10:16:29 PM9/21/15
to django-d...@googlegroups.com

On Sep 21, 2015, at 7:10 PM, "Podrigal, Aron" <ar...@guaranteedplus.com> wrote:

> There is actually another reason to not have to specify a max_length which was mentioned earlier, is because most of the time you don't care about that and is just tedious to have to specify that when you can get it to work without it. Default values has always been here for that reason.

I'm afraid I must disagree that "most of the time you don't care about it." I certainly do. I'm always reasonably careful to specify a max_length that corresponds to the underlying data.

There's no "sensible" default for max_length. It entirely depends on the data you are storing. Picking a backend-specific max_length means that application writers now have no idea how much data the CharField can store: 1GB-ish-depending-on-encoding? 255? 4000 or something less depending on Oracle's encoding?

Requiring a max_length is enforcing a good practice.

Shai Berger

unread,
Sep 21, 2015, 10:22:28 PM9/21/15
to django-d...@googlegroups.com
Hi,

I just went over the ticket and thread. There seem to be two concerns mixed
here.

Most people who expressed support for the feature have just been annoyed at
the need to specify a length when all they want to say is "a reasonably short
string" or "a one-liner".

Aron, on the other hand, seems to aim mostly at an option to remove the length
limitation completely.

I can see why "unlimited" makes sense, sometimes, on Postgres. But I think
it's a bad default for general use, especially in reusable apps.

I also don't like the interpretation of "unlimited" as "backend-specified max",
basically for the reasons Christoph mentioned (same schema on different
backends), and also because I'm concerned about the performance implications
of unnecessarily large fields and about the ambiguity of introspection.

I'd solve the "need to specify" issue by setting a default that is
intentionally smaller than the smallest (core) backend limitation, say 128.
I"d make an "unlimited length text field" a new type of field, explicitly not
supported on MySql and Oracle; and I'd suggest that it can live outside core
for a while. so we may get an impression of how popular it really is.

My 2 cents,
Shai.

Christophe Pettus

unread,
Sep 21, 2015, 10:26:35 PM9/21/15
to django-d...@googlegroups.com

On Sep 21, 2015, at 7:22 PM, Shai Berger <sh...@platonix.com> wrote:

> I'd solve the "need to specify" issue by setting a default that is
> intentionally smaller than the smallest (core) backend limitation, say 128.

I'd be OK with that. Not wild, because I think that having to specify max_length is good discipline, but not everyone likes oatmeal, either. :)

> I"d make an "unlimited length text field" a new type of field, explicitly not
> supported on MySql and Oracle; and I'd suggest that it can live outside core
> for a while. so we may get an impression of how popular it really is.

We kind of have that: TextField. The problem is that TextField has very different performance characteristics and implementation details on PostgreSQL vs MySQL and Oracle. I don't think we need another: If you know you are running on PostgreSQL, you just use TextField, and if you are either targeting a different database, or writing one that runs on multiple ones, you probably want CharField with a specific length.

Podrigal, Aron

unread,
Sep 21, 2015, 10:33:49 PM9/21/15
to Django developers (Contributions to Django itself)
On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus <x...@thebuild.com> wrote:

On Sep 21, 2015, at 7:22 PM, Shai Berger <sh...@platonix.com> wrote:

> I'd solve the "need to specify" issue by setting a default that is
> intentionally smaller than the smallest (core) backend limitation, say 128.

I'd be OK with that.  Not wild, because I think that having to specify max_length is good discipline, but not everyone likes oatmeal, either. :)

OK, this satisfies me too. 

> I"d make an "unlimited length text field" a new type of field, explicitly not
> supported on MySql and Oracle; and I'd suggest that it can live outside core
> for a while. so we may get an impression of how popular it really is.

We kind of have that: TextField.  The problem is that TextField has very different performance characteristics and implementation details on PostgreSQL vs MySQL and Oracle.  I don't think we need another: If you know you are running on PostgreSQL, you just use TextField, and if you are either targeting a different database, or writing one that runs on multiple ones, you probably want CharField with a specific length.

While this makes sense, the use of TextField is also for the purpose of having rendered a text widget for ModelForms. So we should allow a max_length of None for both.
 

--
-- 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-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.

For more options, visit https://groups.google.com/d/optout.

Josh Smeaton

unread,
Sep 22, 2015, 12:22:33 AM9/22/15
to Django developers (Contributions to Django itself)
> While this makes sense, the use of TextField is also for the purpose of having rendered a text widget for ModelForms. So we should allow a max_length of None for both.

If you use Oracle (or mysql I guess), you get used to manually changing the form field widget to be a TextArea if that's what you want for your UI. Using TextField with Oracle is a horrible experience unless you must have it.

Aymeric Augustin

unread,
Sep 22, 2015, 1:49:44 AM9/22/15
to django-d...@googlegroups.com
Hi Aron,

On 22 sept. 2015, at 03:12, Podrigal, Aron <ar...@guaranteedplus.com> wrote:

> 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.

This isn’t possible in a project that uses multiple databases, say PostgreSQL and Oracle. The form layer cannot say which length is correct because it has doesn’t know in what database the data will be saved.

--
Aymeric.




Aymeric Augustin

unread,
Sep 22, 2015, 1:56:51 AM9/22/15
to django-d...@googlegroups.com
Hi Shai,

On 22 sept. 2015, at 04:22, Shai Berger <sh...@platonix.com> wrote:

> I'd solve the "need to specify" issue by setting a default that is
> intentionally smaller than the smallest (core) backend limitation, say 128.

I would pick the highest value supported by all core backends (probably 255
for MySQL, unless there’s something about indexes and multi-byte encodings
that I forget) in order to minimize the need to increase it.

If we go for a lower value, I suggest to pick something totally arbitrary like
100 to make it clear that it isn't a technical limitation.

> I"d make an "unlimited length text field" a new type of field, explicitly not
> supported on MySql and Oracle; and I'd suggest that it can live outside core
> for a while. so we may get an impression of how popular it really is.

The main use case seems to be “VARCHAR() on PostgreSQL”. What about defining a
slight variant of CharField in django.contrib.postgres that merely makes the
max_length argument default to None?

--
Aymeric.

Podrigal, Aron

unread,
Sep 22, 2015, 1:58:05 AM9/22/15
to Django developers (Contributions to Django itself)

Aymeric, thanks for clarification, my bad I missed that one. We will be using max_length=255 or 128 for the default as Shia proposed.

BTW how is this handled by integer_ranges on per database backend? Also, using checks_framework can we validate this setting?

--
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.

Aymeric Augustin

unread,
Sep 22, 2015, 2:03:53 AM9/22/15
to django-d...@googlegroups.com
On 22 sept. 2015, at 07:57, Podrigal, Aron <ar...@guaranteedplus.com> wrote:

We will be using max_length=255 or 128 for the default as Shia proposed.

Would you mind giving a few hours for other contributors to react? I was asleep while you were having this discussion; not every contributor is hooked to django-developers, especially technical board members.

BTW how is this handled by integer_ranges on per database backend?

I was asking myself the same question after seeing https://code.djangoproject.com/ticket/14094#comment:15. I don’t know; perhaps it doesn’t! It’s worth investigating.

-- 
Aymeric.




Podrigal, Aron

unread,
Sep 22, 2015, 2:56:58 AM9/22/15
to Django developers (Contributions to Django itself)

Ok, I'll wait for other contributors to react.

--
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.

Remco Gerlich

unread,
Sep 22, 2015, 7:56:04 AM9/22/15
to django-d...@googlegroups.com


On Mon, Sep 21, 2015 at 11:49 PM, Podrigal, Aron <ar...@guaranteedplus.com> wrote:
We're not talking about representing all CharFields as TEXT, it is about choosing a sane length as the default for the varchar datatype. So if you would not specify max_length, for MySQL it would be varchar(255), for oracle it would be varchar(4000 / bytes_per_char_for NLS_CHARACTERSET) and for PostgreSQL it would be just VARCHAR without a length.

I feel that IF a "sane length as the default" exists, then it must be the same for all database backends. The errors you get from a ModelForm on a web page shouldn't change depending on the database backend!

Maybe django.contrib.postgres could have a ArbitraryLengthCharField?

Greetings,
Remco Gerlich

Tim Chase

unread,
Sep 22, 2015, 7:59:45 AM9/22/15
to Aymeric Augustin, django-d...@googlegroups.com
On 2015-09-22 07:49, Aymeric Augustin wrote:
> > 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.
>
> This isn’t possible in a project that uses multiple databases, say
> PostgreSQL and Oracle. The form layer cannot say which length is
> correct because it has doesn’t know in what database the data will
> be saved.

Could this be resolved with allowing max_length=None (or some other
atom such as just object() that would have a unique id() that could
be tested with "is") to specify that the back-end uses the max-allowed
value? For Postgres, this would then use VARCHAR() with no limit,
while on MySQL, that could be 255 or whatever.

One could then include a helper function that would use the current
settings to check a string (such as from a form) to ensure that it
doesn't exceed the field's database-specific max-length (or whatever
the specified max-length value is).

-tim




Collin Anderson

unread,
Sep 22, 2015, 8:41:10 AM9/22/15
to django-d...@googlegroups.com
If anyone's curious, the mysql situation is as crazy as you might expect. :)

The max is only determined only by the total row size (65,535 bytes) and the index size (767 bytes default).

Mysql defaults to only allowing 3-byte (no emoji) unicode characters, so 65,535/3=21,845 max across the entire row (the sum of all of the maxes of all char/varchar columns), and each indexed field only gets 767/3=255 characters by default.

If you change to 4-byte unicode characters, (which you should, but django doesn't really help you out #18392), your max_lengths can add up to 65,535/4=16,383 characters, and if you want the field to be indexed, you only get 191 characters (using the default index size). It's possible to only index the first 767/4=191 characters of the field, but django doesn't really support that.

Basically, 255 works pretty well by default, allowing 65,535/3/255=85 3-byte fields per row, and indexes just work if you stick to the default settings.



--
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.

Michael Manfre

unread,
Sep 22, 2015, 10:01:23 AM9/22/15
to django-d...@googlegroups.com
I'm -1 on having a default max_length on CharField. We should encourage developers to be more explicit when defining their models, not less. I've inherited way too many databases that suffered from "VARCHAR(255)" being chosen as the arbitrary "any field storing even a few characters will be this length".

Instead of adding a default (and encouraging bad database schemas), what are thoughts about adding a helper function to allow people to define their own new CharField as a one liner? E.g. ShortCharField = make_max_length_char_field(255)

I agree that the Postgresql specific field should exist in django.contrib.postgres.

Regards,
Michael Manfre


For more options, visit https://groups.google.com/d/optout.



--
GPG Fingerprint: 74DE D158 BAD0 EDF8

Tom Evans

unread,
Sep 22, 2015, 10:05:55 AM9/22/15
to django-d...@googlegroups.com
On Tue, Sep 22, 2015 at 1:49 AM, Podrigal, Aron
<ar...@guaranteedplus.com> wrote:
> Different schemas?? Schema will always be different for each database
> backend according to its datatypes. I really don't understand what your
> concern is. In any case your free to specify a max_length=N where it will be
> the same for all backends.

This change would allow a django site running on postgres that you
could not dump the data from and reimport in to mysql without data
loss. It would make it easy to write non-portable apps without
thinking.

>
> While this makes sense, the use of TextField is also for the purpose of
> having rendered a text widget for ModelForms. So we should allow a
> max_length of None for both.
>

(I'm replying to two emails from you in one, hope that is alright)

No, TextField is used to designate an arbitrary length text field.
Having a widget.Textarea as the default input for this field is just a
default, it is perfectly correct to override the defaults either for
CharField or TextField to provide the desired widget type.

One should not be using models.TextField because a widget.Textarea is
desired for forms, instead it is to tell the database backend that the
column for this field should be an arbitrary length text type.

If the problem that is to be solved is that there is no easy way to
specify an arbitrary length text field that uses an input, this can be
solved with a very simple class:

class TextFieldWithInput(models.TextField):
def formfield(self, **kwargs):
defaults = {'widget': forms.TextInput}
defaults.update(kwargs)
return super(TextfieldWithInput, self).formfield(**defaults)

The main argument seems to be "Its a pain to think about the size of
my data when defining my database tables"; if we aren't thinking about
it then, then when do we think about it? Its kind of important..

Cheers

Tom

Christophe Pettus

unread,
Sep 22, 2015, 1:14:03 PM9/22/15