While working on this PR (https://github.com/pulp/pulp-2to3-migration/pull/295), there was a problem with duplicate units since I added a new "null=True" string field to a unique_together condition.
It appeared some units ended up having a Null value, while others had the empty string (which was not my intention with respect to the uniqueness condition). I ended up fixing the issue by using "blank=True" instead of "null=True". I also found the following in the django docs: Avoid using null on string-based fields such as CharField and TextField because empty string values will always be stored as empty strings, not as NULL. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data;” the Django convention is to use the empty string, not NULL. See: https://docs.djangoproject.com/en/3.1/ref/models/fields/ I am pretty sure I have used "null=True" for string fields within pulp_deb and have also seen examples of it in pulpcore. My question for the community is: Should we be concerned about this, given it is apparently not "the Django convention". Is there any chance this could be problematic, even if the field in question is not part of a unique_together condition? Are there situations where we explicitly rely on a distinction between NULL and empty string (making "going against the Django convention" a conscious choice, rather than an historical accident)? Looking forward to your insights, Quirin Pamp (quba42)
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
