Opened 9 years ago

Last modified 7 years 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


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?

Change History (4)

comment:1 Changed 9 years ago by Aymeric Augustin

Triage Stage: UnreviewedDesign decision needed

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

comment:2 Changed 9 years ago by Jacob

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

comment:3 Changed 9 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 7 years ago by Aymeric Augustin

Triage Stage: Design decision neededAccepted

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.

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