On Thu, Feb 17, 2011 at 12:21 AM, Ernie Miller <er...@metautonomo.us> wrote: > Since your example above used a string in the second where call, it > didn't result in an Arel::Nodes::Equality, so it wasn't ORed.
Even on just that point alone, this is a really bad API idea - it is completely inconsistent, and this will cause subtle and confusing bugs when people change between two otherwise-identical forms of where() argument. And to do it at all breaks the relational algebra idea badly. If I pass a scope to something, and it does several different queries on it using its own where scopes, each of those scopes should further restrict the original scope, not broaden it. With this commit, now neither callers nor callees have any idea what where(:hash => arguments) will result in - whether the returned results will match the conditions hash - unless they have constructed the entire scope from scratch. I also struggle to understand how it was decided that a minor point patch release - for a security issue no less - should include an API behavior change that will cause preexisting code to start getting completely different query results. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
