{{{
from django.db import models
class Location(models.Model):
location_number = models.CharField(max_length=30, unique=True)
name = models.CharField(max_length=128)
class Project(models.Model):
location = models.ForeignKey(Location, on_delete=models.CASCADE,
to_field='location_number', db_column='location_number',
related_name='projects', verbose_name='Standort')
}}}
Then it is possible to construct a `Location` with an empty string for
`location_number`:
{{{
Location.objects.create(location_number='', name='location_name')
}}}
But now if we construct a `ModelForm`, it will not accept this as valid
option, indeed:
{{{
class ProjectForm(forms.ModelForm):
class Meta:
model = Project
fields = ['location']
}}}
This will render a `<select>` with the values of the `to_field` as values,
so:
{{{
<select name="location">
<option value="">location_name</option>
</select>
}}}
now if the form is submitted, it will pass the empty string for
`location`, but the form field will reject it because the field is
required, and it sees this as an empty value.
The problem is thus a bit of a mismatch between what a form does and the
possible values of a model. Unfortunately I don't see an easy solution for
this. Perhaps the checks framework can at least warn if a `ForeignKey`
refers to a `CharField` or another field that can have an empty value.
--
Ticket URL: <https://code.djangoproject.com/ticket/34635>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* resolution: => needsinfo
* component: Uncategorized => Forms
Comment:
Is it not enough to set `blank=True` to a `ForeignKey`?
--
Ticket URL: <https://code.djangoproject.com/ticket/34635#comment:1>
Comment (by Willem Van Onsem):
Yes, but that seems counterintuitive, since it seems to suggest that you
leave the *reference* blank, we here leave the `location_id` blank, but
the form definitely refers to a `Location`. So it seems counterintuitive,
and misleading.
--
Ticket URL: <https://code.djangoproject.com/ticket/34635#comment:2>
Comment (by David Sanders):
imho this is exactly what blank is for :P
https://docs.djangoproject.com/en/4.2/ref/models/fields/#blank
> If True, the field is allowed to be blank … Note that this is different
than null. null is purely database-related, whereas blank is validation-
related. If a field has blank=True, form validation will allow entry of an
empty value.
The key here is that `""` is an empty value. `blank=True` is declaring
that empty values are permissible.
> since it seems to suggest that you leave the *reference* blank
Are you referring to `null/None` ? 🤔
> So it seems counterintuitive, and misleading.
And so the `NULL` debate rages on 😅
--
Ticket URL: <https://code.djangoproject.com/ticket/34635#comment:3>
* resolution: needsinfo => wontfix
Comment:
> Yes, ...
Great, so it works as documented. That's why we have `blank`.
> ... but that seems counterintuitive
We had this debate so many times, we cannot change the long standing
behavior for an edge case of blank primary keys. TBH, I don't find it
misleading that you have to set `blank=True` to allow for blank foreign
keys.
You can start a discussion on DevelopersMailingList if you don't agree,
however, I don't think there would be consensus to change the current
behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/34635#comment:4>