named_scope :order on association with :order is unintuitive

Related issue:

If you have a named scope with a :select, doing

Foo.that_named_scope.find(:all, :select => 'something')

will use the select from the named scope, not the one in the find.

I've come across similar.. in my case I didn't get a comma separated order statement, just the first order param passed in the scope chain.

The attached patch seems to address this issue. It specifically deals with :order alongside :includes, :conditions, and merges them with the last ordering being most important.

Here are some tests.

David, thanks for doing this.

Confirmed that the tests pass.

It does not, however, seem to handle the case where the association is defined with an order, like "has_many :bars, :order => 'one'" above.

Attaching a failing test to this effect that goes on top of David's latest patch.

Not saying the patch should not be accepted without this -- better to fix a little than nothing at all -- but if it's easy to get this, too, that would rock.

Henrik,

You can get the test working by ordering by 'comments.body', and changing the add_order! function in active_record/base.rb, as attached. It assumes you'll want to apply a named scope on an association..

This breaks using a finder on a named scope, though.

David: Thanks! "breaks using a finder on a named scope" only in the sense that the :order from named scopes will always beat the order from associations/finds, right?

So basically one has to choose whether to let associations/finds or named scopes get priority?

Seems like one could modify the calls to add_order! (or check the caller, but that's nasty), so we can tell whether the non-scope order is from an association or a find.

Basically, the add_order! calls from associations.rb could be passed a forth parameter like "association = true", and then association orders could be lower prio than scope orders, but find orders would be higher prio.

Does this make sense? Is it too complicated? I personally would much prefer moderate complication if it means ActiveRecord behaves more intuitively.

I'd be happy to try this out and submit a patch, just wanted to check if it makes sense to someone more familiar with the codebase.

Yes, the named scope ordering beats associations/finds with my changes.

One problem being that in our tests, it's only base.rb#construct_finder_sql that calls add_order! and you don't know much context from there.

I think you're probably right about the priority being dynamic finder < named scope < association ordering.

I just bumped into this in rails 2.2.2 - sad to see it was never merged

Personally I think the reason for the complication suggested above is because the order should in fact simply be from left to right. So if you have

obj.sort_a.sort_b.sort_c

then you get "order a, b, c"

This meets all the requirements above. I don't obviously see that it's consistent that scopes should win out over an earlier specified sort order (although I do agree there are occasions that would be nice). If it's desired to force sort overrides then I think this needs an extra syntax, the general rule of scopes, etc, is that they are cumulative from left to right and so should the sort options to be consistent

Hope to see this in 2.4/3?

The current behaviour also prevents us from explicitly setting the order on top of a named scope:

obj.sort_a :order => "b,c"
#=> "order a"

I would expect that either these be chained for "order a,b,c" or else have the explicit order clobber the one in the named scope.

It seems this also applies to default_scope, which is potentially very confusing because it hides the source of the problem.

Can anybody still confirm this is an issue that needs patching? It's a pretty old ticket.