Changes between Initial Version and Version 3 of Ticket #17038


Ignore:
Timestamp:
Nov 26, 2011, 6:06:23 AM (13 years ago)
Author:
Aymeric Augustin
Comment:

Fixed formatting.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #17038

    • Property Summary Use of _default_manager instead of _base_manager in ForeignKey form field validation → Use of _default_manager instead of _base_manager in ForeignKey ModelForm field validation
    • Property Component Forms → Database layer (models, ORM)
    • Property Easy pickings unset

  • Ticket #17038 – Description

    initial v3  
    11I'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]. 
    22
    3 The bug I am referring to is located in: 
    4 
    5 django/db/models/fields/related.py , line 850
    6 (version 1.3.1) 
     3The bug I am referring to is located in django/db/models/fields/related.py , line 850, (version 1.3.1) 
    74
    85This is in the "validate" method of ForeignKey.  Specifically, the problematic code is:
    96
     7{{{
    108   qs = self.rel.to.'''_default_manager'''.using(using).filter(
    119                *''*''{self.rel.field_name: value}
    … …  
    1513       raise exceptions.ValidationError(self.error_messages['invalid'] % {
    1614            'model': self.rel.to._meta.verbose_name, 'pk': value})
     15}}
    1716
    18 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.
     17To 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.
    1918
    2019The 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.
Back to Top