Opened 9 years ago

Last modified 9 years ago

#26296 closed Cleanup/optimization

Trick with extra fields — at Initial Version

Reported by: aimestereo Owned by: nobody
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

In documentation there's comment in values() section about some behavior of extra

https://docs.djangoproject.com/en/1.9/ref/models/querysets/#django.db.models.query.QuerySet.values

If you use a values() clause after an extra() call, any fields defined by a select argument in the extra() must be explicitly included in the values() call. Any extra() call made after a values() call will have its extra selected fields ignored.

It's points that any extra fields after values() call will be ignored. But I think that it's not correct and need more description.

For example it could be not obvious that next simple construction will cause exception and such an not obvious one!

User.objects.values('username').extra(select={'test_field': 1}).values('test_field', 'username')

FieldError: Cannot resolve keyword 'test_field' into field. Choices are: date_joined, email, first_name, groups, id, is_active, is_staff, is_superuser, last_login, last_name, logentry, password, test_field, user_permissions, username

I want to point out that test_field is listed in choices that's very confusing. It happens because of all checks is runs against extra_select but error is uses extra as part of available choices.

sorted(list(get_field_names_from_opts(opts)) + list(self.extra)
                               + list(self.annotation_select))

I can help you with this small change.

Change History (0)

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