Django SELECT (1) AS [a] FROM [my_table] WHERE ([my_table].[id] = ? AND NOT ([my_table].[id] = ? )) (1, 1)

Why is Django executing statements such as this:

SELECT (1) AS [a] FROM [my_table] 
WHERE ([my_table].[id] = ?  
AND NOT ([my_table].[id] = ? )) (1, 1)

This happens when calling is_valid() on a formset created the following way:

MyFormSet = modelformset_factory(Table, fields=['my_field'], extra=0)
my_form_set = MyFormSet(request.POST,
                        queryset=Table.objects.all())

where Table and MyForm are as si开发者_StackOverflow社区mple as, say:

class Table(models.Model):
    my_field = models.CharField(max_length=10)

class MyForm(forms.ModelForm):
    class Meta:
        model = Table

Hint: I looked at the call stack and the code responsible for it (in django/forms/models.py) is below:

def _perform_unique_checks(self, unique_checks):
    import pdb; pdb.set_trace()
    bad_fields = set()
    form_errors = []

    for unique_check in unique_checks:
        # Try to look up an existing object with the same values as this
        # object's values for all the unique field.

        lookup_kwargs = {}
        for field_name in unique_check:
            lookup_value = self.cleaned_data[field_name]
            # ModelChoiceField will return an object instance rather than
            # a raw primary key value, so convert it to a pk value before
            # using it in a lookup.
            if isinstance(self.fields[field_name], ModelChoiceField):
                lookup_value =  lookup_value.pk
            lookup_kwargs[str(field_name)] = lookup_value

        qs = self.instance.__class__._default_manager.filter(**lookup_kwargs)

        # Exclude the current object from the query if we are editing an
        # instance (as opposed to creating a new one)
        if self.instance.pk is not None:
            qs = qs.exclude(pk=self.instance.pk)

Basically the pk is both included for the uniqueness check and excluded. Looks like Django can be smarter and avoid such inefficiency.

---

I haven't looked at it in detail, but I think you are right that Django could shortcut this query. Please file a ticket at http://code.djangoproject.com/.

---

Looks like this has been fixed already in trunk (by adding new functionality that also fixes this particular problem)