Consider a different interface for get_next_by_FOO and get_previous_by_FOO

[umbrae@…]

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?

[Aymeric Augustin]

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

[Jacob]

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

[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.

[Aymeric Augustin]

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.