Re: Making max_length argument optional

I finally had some time to do some work on this and have submitted a patch at https://github.com/django/django/pull/16302 in case anyone is interested. On Wednesday, October 5, 2022 at 2:24:35 PM UTC+2 carlton...@gmail.com wrote: > Hi Adrian. > > Nothing has been done, no. > > There seem

Re: Making max_length argument optional

Hi Adrian. Nothing has been done, no. There seem to be a few competing options: 1. Allow max_length=None on Postgres (using a supports_unlimited_charfields, name!?, DB backend feature flag maybe 樂) 2. Add an unlimited flag to CharField. 3. Have a subclass in contrib.postgres, similar to JKM's

Re: Making max_length argument optional

Sorry for reviving the thread but just ran into this issue again and wanted to ask, has there anything been done to address this? For me having max_length=None mean "unlimited varchar" for Postgres and being an error for any other database (or those that don't support unlimited varchar) is the

Re: Making max_length argument optional

It would work for my use-cases. It was mentioned that it's maybe not the best as a lot of fields subclass CharField, but I don't see a compelling argument for an unlimited email or slug field. The one problem I see is CICharField, you might want to make that unlimited - but the CI fields are more

Re: Making max_length argument optional

Would the subclass in contrib.postgres suggestion be acceptable? On Mon, 17 Aug 2020 at 10:31, Tom Carrick wrote: > I'm not a fan of any solution either, really, even the one I suggested. > > I think adding a new kwarg, "unlimited" seems okay to me, though it feels > a little redundant. > > I

Re: Making max_length argument optional

I'm not a fan of any solution either, really, even the one I suggested. I think adding a new kwarg, "unlimited" seems okay to me, though it feels a little redundant. I don't like the idea of using TextField, I find them semantically different. An unlimited varchar says to me "one possibly very

Re: Making max_length argument optional

Reading the history, I see an awful lot of -1s to the idea of a default. I see “use a TextField” and “use a subclass” a few times, which were my immediate thoughts just on the recent emails. On Sun, 16 Aug 2020 at 18:47, Tom Forbes wrote: > I’m not a fan of implicit max_lengths. Is having to

Re: Making max_length argument optional

I’m not a fan of implicit max_lengths. Is having to add a keyword argument to a model field really that much of a burden? And we also would likely never be able to change the default without headaches. > On 12 Aug 2020, at 13:19, t...@carrick.eu wrote: > > I'd like to revive this discussion

Re: Making max_length argument optional

My 2 cents as a non core developer. On Wednesday, August 12, 2020, t...@carrick.eu wrote: > > > Give CharField a default max_length that is consistent across all vendors. > It doesn't really matter what the number is other than that it should be > large enough to be useful but small enough to

Re: Making max_length argument optional

I'd like to revive this discussion and try to come to a consensus as it's something I find myself wishing for (for Postgres in particular). My suggestion, after reading through everything: Give CharField a default max_length that is consistent across all vendors. It doesn't really matter what

Re: Making max_length argument optional

On Saturday 05 March 2016 02:24:17 Loïc Bistuer wrote: > I’m not too keen on a contrib.pg field. CharField is the base class of many > fields, a __init__ kwarg approach such as max_length=None allows us to > reach those as well. > That's a good point; Can we enable max_length=None in a mixin?

Re: Making max_length argument optional

I’m not too keen on a contrib.pg field. CharField is the base class of many fields, a __init__ kwarg approach such as max_length=None allows us to reach those as well. > On Mar 5, 2016, at 3:05 AM, Marc Tamlyn wrote: > > Voting: > > 1) should there be a default? > >

Re: Making max_length argument optional

Voting: 1) should there be a default? I'm lazy, so I would be happy to have one. Where validation matters you can change it, where it doesn't you don't have to. I'd draw an analogy to (Positive)(Small)IntegerField - I often use the normal one when I mean some variant of validation, or some other

Re: Making max_length argument optional

>From what I understand you will have a hard time doing that at all: On PG could go with a 'max_length=None' in a 3rd party app. But that wouldn't be supported on any other database backend. Which means you're limiting your app to PG. On the other hand you could make your app database

Re: Making max_length argument optional

I find that using TextField rather than CharField just to make postgres use varchar() is a terrible idea, if you are implementing an reusable app and it is used on a backend like MySQL where TextFields are created as text columns which are horribly inneficient and should be avoided at any cost

Re: Making max_length argument optional

Hi, Thank you, Aymeric, for summing up the discussion this way. The division into two separate problems is indeed required, and I fully support the idea of setting max_length's default to 100 or 120. There seem to be just two points worth adding to your summary: On Monday 29 February 2016

Re: Making max_length argument optional

Hello, This thread is getting long. It contains lots of valid arguments. In the interest of seeking consensus, here’s a tentative summary. Problem Typing `foo = models.CharField(max_length=100)` gets old quickly. Can we skip the `max_length` argument in many cases? Constraints Character

Re: Making max_length argument optional

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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

On Sunday 28 February 2016 12:23:50 Florian Apolloner wrote: > On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote: > > We could also potentially add another sentinel like > > DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly > > documented, for the sake of 3rd

Re: Making max_length argument optional

On Sunday, February 28, 2016 at 11:33:16 AM UTC+1, Loïc Bistuer wrote: > > I don't think this is a problem, we could validate that the backend > supports it during save then blow up if we detect it doesn't. I think we do > that for truncation on MySQL. If the model specifies something that the

Re: Making max_length argument optional

I don't think this is a problem, we could validate that the backend supports it during save then blow up if we detect it doesn't. I think we do that for truncation on MySQL. If the model specifies something that the db doesn't support it's a configuration problem, not a user validation problem.

Re: Making max_length argument optional

On Sunday, February 28, 2016 at 9:57:27 AM UTC+1, Luke Plant wrote: > > We could also potentially add another sentinel like > DB_MAX_UNICODE_SAFE_LENGTH that works as you expect and is clearly > documented, for the sake of 3rd party apps, and comes with the caveat that > it produces different

Re: Making max_length argument optional

Replying to this and the other emails in the thread: Django should not be settling low arbitrary limits for the sake of a database I'm not even using, that's just crazy. Limits as high as 120 are not "big enough for anyone", and will cause problems. (I can give lots of examples). Maximum field

Re: Making max_length argument optional

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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

Hi Florian, Wim and all, On Saturday 27 February 2016 16:56:25 Florian Apolloner wrote: > Hi Wim, > > On Saturday, February 27, 2016 at 2:33:27 PM UTC+1, Wim Feijen wrote: > > Can you please elaborate why the current situation is better? > > I wouldn't say it is better, just equally good/bad ;)

Re: Making max_length argument optional

Hi Wim, On Saturday, February 27, 2016 at 2:33:27 PM UTC+1, Wim Feijen wrote: > > Can you please elaborate why the current situation is better? > I wouldn't say it is better, just equally good/bad ;) > In practice, most people add max_length=255 everytime by hand. I value > your opinion but

Re: Making max_length argument optional

Hi Florian, Can you please elaborate why the current situation is better? In practice, most people add max_length=255 everytime by hand. I value your opinion but I fail to understand your reasoning. Could you please explain further (if you have time)? Wim On Saturday, 27 February 2016

Re: Making max_length argument optional

-1 on adding an arbitrary default like 100/128… If people choose a CharField the should set max_length manually. In that sense I am for option 3. Cheers, Florian On Saturday, February 27, 2016 at 1:55:23 PM UTC+1, Wim Feijen wrote: > > Hi guys, > > I'd like to reach consensus about >

Re: Making max_length argument optional

Hi guys, I'd like to reach consensus about https://code.djangoproject.com/ticket/14094 In the discussion, I saw three options: 1. Adding a default max_length = None, which may in practice differ per database backend. 2. Adding a default max_length of a value which can be used across

Re: Making max_length argument optional

I'm with Tom here. Forcing `max_length` to always be set on CharField feels like the right decision. Having a default there seems unnecessary obscure, and more likely to lead to untested/unnoticed failure cases. It *could* be that we'd allow `max_length=None` to explicitly turn off the

Re: Making max_length argument optional

On Sep 22, 2015, at 1:01 AM, Remco Gerlich wrote: > Maybe django.contrib.postgres could have a ArbitraryLengthCharField? Just a note that, on PostgreSQL, that's exactly what TextField is. There might be a use for a field that creates a VARCHAR without length on PostgreSQL,

Re: Making max_length argument optional

On Tue, Sep 22, 2015 at 1:49 AM, Podrigal, Aron 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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

On Mon, Sep 21, 2015 at 11:49 PM, Podrigal, Aron 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

Re: Making max_length argument optional

Ok, I'll wait for other contributors to react. On Sep 22, 2015 2:03 AM, "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote: > On 22 sept. 2015, at 07:57, Podrigal, Aron > wrote: > > We will be using max_length=255 or 128 for the default as Shia proposed. > >

Re: Making max_length argument optional

On 22 sept. 2015, at 07:57, Podrigal, Aron 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

Re: Making max_length argument optional

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? On Sep 22, 2015 1:49 AM, "Aymeric

Re: Making max_length argument optional

Hi Shai, On 22 sept. 2015, at 04:22, Shai Berger 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

Re: Making max_length argument optional

Hi Aron, On 22 sept. 2015, at 03:12, Podrigal, Aron 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

Re: Making max_length argument optional

> 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

Re: Making max_length argument optional

On Mon, Sep 21, 2015 at 10:26 PM, Christophe Pettus wrote: > > On Sep 21, 2015, at 7:22 PM, Shai Berger wrote: > > > I'd solve the "need to specify" issue by setting a default that is > > intentionally smaller than the smallest (core) backend limitation,

Re: Making max_length argument optional

On Sep 21, 2015, at 7:22 PM, Shai Berger 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

Re: Making max_length argument optional

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,

Re: Making max_length argument optional

On Sep 21, 2015, at 7:10 PM, "Podrigal, Aron" 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

Re: Making max_length argument optional

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. On Mon,

Re: Making max_length argument optional

On Sep 21, 2015, at 6:12 PM, "Podrigal, Aron" 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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

On Sep 21, 2015, at 5:49 PM, "Podrigal, Aron" 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

Re: Making max_length argument optional

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. On Mon, Sep 21, 2015 at 8:42 PM, Christophe Pettus

Re: Making max_length argument optional

On Sep 21, 2015, at 2:49 PM, "Podrigal, Aron" 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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

On Sep 21, 2015, at 9:54 AM, 'Tom Evans' via Django developers (Contributions to Django itself) 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

Re: Making max_length argument optional

On Mon, Sep 21, 2015 at 5:21 PM, Paulo Maciel 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

Re: Making max_length argument optional

+1 max_length optional Em quarta-feira, 29 de julho de 2015 01:27:59 UTC-3, Aron Podrigal escreveu: > > 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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

> Le 29 juil. 2015 à 18:25, Podrigal, Aron 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

Re: Making max_length argument optional

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

Re: Making max_length argument optional

Ticket is https://code.djangoproject.com/ticket/14094 On Wednesday, July 29, 2015 at 1:41:01 AM UTC-4, Loïc Bistuer wrote: > > 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 >

Re: Making max_length argument optional

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