Code

Opened 3 years ago

Last modified 16 months ago

#16505 new New feature

Consider a different interface for get_next_by_FOO and get_previous_by_FOO

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

Description

Recently I was looking to use these methods along with a deferred query. As I quickly found out, it's impossible - in order to defer I'll have to implement all of the get_next_by logic separately. That's because these methods are tied directly to a model. You can't defer because it's not part of a manager.

I'm no django expert (yet), but I'm wondering if these methods might be better suited, in the long term, off of .objects instead - so something like the following would work:

some_blog = Blog.objects.get(pk=1)

# Get the next one by passing in a model
older_blog = Blog.objects.get_next_by_date_added(some_blog)

# Get the next one by passing in a datetime object itself
older_blog = Blog.objects.get_next_by_date_added(some_blog.date_added) 

# Get the next blog, but don't get pull out content because it's unnecessary.
deferred_older_blog = Blog.objects.defer('content').get_next_by_date_added(some_blog) 

Any thoughts here?

Attachments (0)

Change History (4)

comment:1 Changed 3 years ago by aaugustin

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

The idea looks valid. However, we need the approval of a core developer for such API changes.

comment:2 Changed 3 years ago by jacob

Are you proposing dropping Model.get_(next|prev)_by_FOO or augmenting it with new queryset methods?

comment:3 Changed 3 years ago by umbrae@…

In a perfect world, I'd rather there be only one way to do it, so I suppose I'm proposing deprecating and eventually removing Model.get_(next|prev)_by_FOO in favor of new queryset methods. In the near term there could be overlap though, of course.

I know that's a long road and potentially a painful change for users for a relatively small gain, so I'd leave that call up to you guys.

comment:4 Changed 16 months ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

Yes, it would make much more sense to have qs.get_next(obj, *fields), where fields would default to Meta.ordering.

It would also make it possible to find the next/previous object for models ordered by multiple fields.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.