#17038: Use of _default_manager instead of _base_manager in ForeignKey
ModelForm
field validation
-------------------------------------+-------------------------------------
Reporter: ben@… | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 1.3
(models, ORM) | Resolution:
Severity: Normal | Triage Stage:
Keywords: manager form | Unreviewed
validation ForeignKey | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Description changed by aaugustin:
Old description:
> I'm not absolutely convinced this is a bug, but it is causing me grief
> and appears to be a bug when considered against
> [https://docs.djangoproject.com/en/dev/topics/db/managers/#controlling-
> automatic-manager-types Django's documented methodology with respect to
> "plain" manager usage vs. default manager usage].
>
> The bug I am referring to is located in
> django/db/models/fields/related.py , line 850, (version 1.3.1)
>
> This is in the "validate" method of ForeignKey. Specifically, the
> problematic code is:
>
> {{{
> qs = self.rel.to.'''_default_manager'''.using(using).filter(
> *''*''{self.rel.field_name: value}
> )
> qs = qs.complex_filter(self.rel.limit_choices_to)
> if not qs.exists():
> raise exceptions.ValidationError(self.error_messages['invalid'] %
> {
> 'model': self.rel.to._meta.verbose_name, 'pk': value})
> }}
>
> To me, this should be using `_base_manager` instead of `_default_manager`
> in order to be consistent with Django's stated plain vs. default
> "automatic manager" paradigm for foreign key lookups.
>
> The specific problem I am running into is that my default manager's
> get_queryset method filters out a significant number of records (archived
> records), but I also have a secondary manager which includes them. In my
> form, I have an option to load a ModelChoiceField using the queryset from
> the secondary manager, including the archived records. However,
> validation for my form fails if a archived record is selected, since the
> above code looks to the default manager (which excludes all archived
> records) for validation instead of a "plain" manager.
>
> I am looking at creating a custom field in order to override the validate
> method as a work around, but this seemed like a potential bug to me.
>
> This is my first bug report, so let me know if other information will be
> useful.
>
> Ben
New description:
I'm not absolutely convinced this is a bug, but it is causing me grief and
appears to be a bug when considered against
[https://docs.djangoproject.com/en/dev/topics/db/managers/#controlling-
automatic-manager-types Django's documented methodology with respect to
"plain" manager usage vs. default manager usage].
The bug I am referring to is located in django/db/models/fields/related.py
, line 850, (version 1.3.1)
This is in the "validate" method of ForeignKey. Specifically, the
problematic code is:
{{{
qs = self.rel.to.'''_default_manager'''.using(using).filter(
*''*''{self.rel.field_name: value}
)
qs = qs.complex_filter(self.rel.limit_choices_to)
if not qs.exists():
raise exceptions.ValidationError(self.error_messages['invalid'] % {
'model': self.rel.to._meta.verbose_name, 'pk': value})
}}}
To me, this should be using `_base_manager` instead of `_default_manager`
in order to be consistent with Django's stated plain vs. default
"automatic manager" paradigm for foreign key lookups.
The specific problem I am running into is that my default manager's
get_queryset method filters out a significant number of records (archived
records), but I also have a secondary manager which includes them. In my
form, I have an option to load a ModelChoiceField using the queryset from
the secondary manager, including the archived records. However,
validation for my form fails if a archived record is selected, since the
above code looks to the default manager (which excludes all archived
records) for validation instead of a "plain" manager.
I am looking at creating a custom field in order to override the validate
method as a work around, but this seemed like a potential bug to me.
This is my first bug report, so let me know if other information will be
useful.
Ben
--
--
Ticket URL: <https://code.djangoproject.com/ticket/17038#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
