Opened 5 years ago

Closed 22 months ago

#10702 closed New feature (wontfix)

.extra() should accept "having" parameter

Reported by: carljm Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: kelmens@…, bas@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Now that we can construct ORM queries with aggregates, it would be nice if the .extra() queryset method accepted a "having" parameter. It would work just like the current "where" parameter; would probably need an associated "having_params" argument, too.

Attachments (0)

Change History (11)

comment:1 Changed 5 years ago by Alex

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

I am almost positive I saw malcolm reject a similar suggestion before, however since I can't find it I'm going to mark as DDN.

comment:2 Changed 5 years ago by django@…

I would also like to see this feature. I am using a local implementation as a workaround to #11293, where HAVING clauses lose their connectors. This feature would also need to be taken into account for any fix to #11104.

comment:3 Changed 4 years ago by carljm

@Alex I know that new QuerySet _methods_ that map directly to SQL implementation have often been rejected (with good reason, IMO), but extra() is in a different category: it's already tied directly to SQL terms and implementations. This proposal doesn't change the nature of extra(), just fleshes out its functionality.

comment:4 Changed 4 years ago by fetzig

  • Cc kelmens@… added

comment:5 Changed 4 years ago by fetzig

whats the use of being able use aggregates and not being able to set a having cause?

why is after a year still a "Design decision needed"?

comment:6 Changed 4 years ago by parxier

  • Cc bas@… added

comment:7 Changed 3 years ago by sethtrain

  • Severity set to Normal
  • Type set to New feature

comment:8 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:9 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:10 Changed 22 months ago by anonymous

3 years and this still isn't fixed?

So people on mysql can use extra to specify extra params, but the only way to do filtering on those is via the HAVING clause, as the WHERE clause isn't aware of those params.

So if comment #1 is correct, and this was rejected for some ridiculous reason, then it almost looks like explicitly targeting mysql users, as other db users can use the standard extra(where=...) to handle filtering, but mysql users are denied access to HAVING because of one asshole with a head full of bad decisions, who probably didn't even understand the ramifications of his actions.

So for mysql users, there is NO WAY TO FILTER USING THE PARAMS DEFINED IN EXTRA. Is this more or less correct? And no one has any intention of fixing it?

Isn't that precious!

comment:11 Changed 22 months ago by Alex

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

We've generally been in the direction of restricting (and hopefully) removing extra(), rather than expanding it. Therefore wontfixing this.

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.