Hi Raffaele. Looking at #10244, it looks as if it needs someone to pick up Aymeric's suggestion. Would that be you? đ (Since you favour the option 2 there, I'd try that â it's probably OK with a suitable release note, as Aymeric said.) C.
On Tuesday, 27 July 2021 at 23:46:33 UTC+2 Raffaele Salmaso wrote: > Hi all, > related to these tickets I want to remind this old ticket > https://code.djangoproject.com/ticket/10244 which needs a decision. > > Thanks! > > On Sun, Jul 25, 2021 at 3:12 PM Jacob Walls <jacobty...@gmail.com> wrote: > >> Hi group, >> >> We have several accepted tickets regarding developer headaches when a >> blank=True field, which skips model validation by design[1], contains >> inappropriate empty values (e.g. None for a not-nullable field or the empty >> string where empty strings aren't allowed). I want to see what the >> community thinks is reasonable here and move them to a resolution or >> potentially wontfix them. >> >> # 22224 â CharField <http://code.djangoproject.com/ticket/22224> (None >> from an application/json encoded payload isnât cleaned to empty string) >> >> # 27697 â JSONField <http://code.djangoproject.com/ticket/27697> (None >> isnât cleaned to â{}â) >> >> # 20205 â PositiveIntegerField >> <http://code.djangoproject.com/ticket/20205> (empty string unexpectedly >> passes model validation if blank=True. In this case the user was opting-in >> to model validation.) >> >> *** >> >> For 22224âCharFieldâwe could take Simonâs proposal >> <https://code.djangoproject.com/ticket/22224#comment:5> to last-minute >> cast None to empty string in get_db_prep_value() if the fieldâs >> empty_strings_allowed is True and null=False. >> >> For 27696âJSONFieldâsimilarly, we could cast from None to "{}" if >> null=False. >> >> For 20205âPositiveIntegerField, and by extension, any field where >> empty_strings_allowed is Falseâwe might run model validation if we have an >> empty string to ensure we fail at the model level instead of the db, >> although this is not the usual practice for blank=True fields. See PR >> <https://github.com/django/django/pull/14666>. >> >> The backwards compatibility concerns seem limited, because users are >> presumably working around these edge cases today, since invalid data is not >> being saved to the database. But there is the question of how much effort >> to expend here. Iâm willing to see these through if we have a consensus >> around the best way to proceed. >> >> All best, >> >> Jacob >> >> >> [1] blank=True and null=False and injecting-data-before-save being an >> idiom we donât want to remove, see: >> https://code.djangoproject.com/ticket/22224#comment:7 >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/58616ad3-54b6-4b21-b252-96040680fa04n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/58616ad3-54b6-4b21-b252-96040680fa04n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > | Raffaele Salmaso > | https://salmaso.org > | https://bitbucket.org/rsalmaso > | https://github.com/rsalmaso > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e694a082-48da-44bc-b3c0-5503176b91c9n%40googlegroups.com.