On 27/12/11 14:32, Matt jones wrote:
https://github.com/rails/rails/pull/4082
I've commented on the PR.
On a related note, the current mechanism for handling 'reorder' seems
pretty strange; what's the design motivation behind keeping the values
passed to reorder separate from order?
The reason is so that we can handle eagerly defined scopes correctly.
For example, consider:
class Post < AR::Base
scope :by_bla, reorder('bla')
end
At the time the scope is defined, it is effectively:
class Post < AR::Base
def self.by_bla
Post.reorder('bla')
end
end
If we 'collapsed' the order values at this point, when we later do, e.g.
Post.order('foo').by_bla
We are effectively doing:
Post.order('foo').merge Post.reorder('bla')
=> Post.order('foo').merge Post.scoped
=> Post.order('foo')
The 'foo' order would not be replaced because at the execution time we
don't have the information to know that 'by_bla' is supposed to trigger
a reordering.
The root problem is that we allow eagerly evaluated scopes to be defined
at all. Personally I dislike 'scope' and would rather that we just told
people to define their own class methods (which of course only get
evaluated when they are actually used). Others like the brevity of the
single line 'scope' syntax.
For Rails 4 I would like to discuss making use of the new lambda syntax
as a compromise, e.g.
scope :by_bla, -> { reorder('bla') }
As a side-effect of that
implementation, this code:
SomeModel.order('foo ASC').reorder('bar DESC').order('baz ASC')
does not (as might be expected) sort the returned record by baz - the
reorder overrides all previous *and* subsequent orders.
I think this is a bug.
--
http://jonathanleighton.com/
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
