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

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 ve

Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?

Looking through blame, it looks like this hardcoded salt was added in 2010: https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90 This actually changed from using the secret key as the salt, to

Re: Why using django.contrib.sessions as the salt to encode session data? why not secret key?

Looking at the code, the hard-coded salt seems OK to me. The encoding is done by SessionBase.encode() , which calls dumps() from django.core.signing

Re: Model-level validation

It sounds like there is little support for this being the default. But I'd like to propose something that might satisfy the different concerns: 1) A `validate` kwarg for `save()`, defaulted to `False`. This maintains backwards compatibility and also moves the validation behavior users coming to

Re: Model-level validation

FWIW +1 from me! -- C On Thu, 6 Oct 2022, at 14:11, Aaron Smith wrote: > It sounds like there is little support for this being the default. But I'd > like to propose something that might satisfy the different concerns: > > 1) A `validate` kwarg for `save()`, defaulted to `False`. This maintain

Re: Model-level validation

אורי u...@speedy.net On Thu, Oct 6, 2022 at 6:11 AM Aaron Smith wrote: > It sounds like there is little support for this being the default. But I'd > like to propose something that might satisfy the different concerns: > > 1) A `validate` kwarg for `save()`, defaulted to `False`. This maintains