#33682: Clarify using distinct() with related fields that have Meta.ordering
defined.
--------------------------------------+------------------------------------
     Reporter:  Robert Leach          |                    Owner:  nobody
         Type:  Cleanup/optimization  |                   Status:  new
    Component:  Documentation         |                  Version:  3.2
     Severity:  Normal                |               Resolution:
     Keywords:  sql, distinct         |             Triage Stage:  Accepted
    Has patch:  0                     |      Needs documentation:  0
  Needs tests:  0                     |  Patch needs improvement:  0
Easy pickings:  0                     |                    UI/UX:  0
--------------------------------------+------------------------------------

Comment (by Robert Leach):

 That's definitely better, as it directly references Meta.ordering, which
 is a great clue to what the implications are.  What do you think about
 **adding** something like:

 > If all you want is to make a set of query results distinct without
 changing the ordering, note you must explicitly "re-"add the otherwise
 over-ridden fields defined in Meta.ordering.  But be careful, if you
 simply add those fields, you can run afoul of the matching fields
 requirement between order_by and distinct.  The field(s) defined in
 Meta.ordering can include a foreign key, which will resolve differently in
 order_by (to the related model's Meta.ordering field(s)) and distinct (the
 `_id`) and the fields will no longer match between the 2 expressions.
 >
 > But this gotcha can be entirely avoided by only ever using real database
 fields in every `Meta.ordering`, `order_by`, and `distinct` list instead
 of adding Django's related model objects (e.g. `ForeignKey`,
 `ManyToManyField`, `OneToManyField`, etc.) so as not to rely on Django's
 differing related-model-object to database-field resolving mechanisms
 (e.g. instead of adding `blog` to `Entry.Meta.ordering`, add
 `blog__name`).

 ...but like I said, all the info is there to either put it together and
 anticipate it (albeit requiring a fairly deep understanding and more
 experience to achieve those insights), or to interpret the exception.  I
 just feel like piecing together this (what I would consider common) use-
 case, may make it clearer to those who are endeavoring into their first
 big Django project and applying complex understandings of and experiences
 with other programming languages.

 Whatever edit gets included, I would like to say that I very much
 appreciate your attention to this topic.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/33682#comment:9>
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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070180b8e49e3b-33580446-18f5-4a87-8680-cf6eb6733b0a-000000%40eu-central-1.amazonses.com.

Reply via email to