Opened 4 years ago

Closed 4 years ago

#17038 closed Bug (duplicate)

Use of _default_manager instead of _base_manager in ForeignKey ModelForm field validation

Reported by: ben@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords: manager form validation ForeignKey
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by aaugustin)

I'm not absolutely convinced this is a bug, but it is causing me grief and appears to be a bug when considered against 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

Change History (5)

comment:1 Changed 4 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Summary changed from Use of _default_manager instead of _base_manager in ForeignKey form field validation to Use of _default_manager instead of _base_manager in ForeignKey ModelForm field validation

comment:2 Changed 4 years ago by anonymous

  • Component changed from Forms to Database layer (models, ORM)

comment:3 Changed 4 years ago by aaugustin

  • Description modified (diff)
  • Easy pickings unset

Fixed formatting.

comment:4 Changed 4 years ago by aaugustin

  • Description modified (diff)

comment:5 Changed 4 years ago by carljm

  • Resolution set to duplicate
  • Status changed from new to closed

This is a duplicate of #14891

Note: See TracTickets for help on using tickets.
Back to Top