- 06 7月, 2013 1 次提交
-
-
由 Vipul A M 提交于
Perf ref: https://gist.github.com/vipulnsward/8209749201dfdd678c97
-
- 28 6月, 2013 2 次提交
-
-
由 Carlos Antonio da Silva 提交于
In 94924dc3 the internal default_scope implementation has changed making it simpler to follow, meaning that the old usage of with_default_scope has been removed. With that, order_values was the same argument for both calls to find_first_with_limit, so remove it and use the existent attribute for the sake of clarity/simplification.
-
由 Jon Leighton 提交于
The previous implementation was necessary in order to support stuff like: class Post < ActiveRecord::Base default_scope where(published: true) scope :ordered, order("created_at") end If we didn't evaluate the default scope at the last possible moment before sending the SQL to the database, it would become impossible to do: Post.unscoped.ordered This is because the default scope would already be bound up in the "ordered" scope, and therefore wouldn't be removed by the "Post.unscoped" part. In 4.0, we have deprecated all "eager" forms of scopes. So now you must write: class Post < ActiveRecord::Base default_scope { where(published: true) } scope :ordered, -> { order("created_at") } end This prevents the default scope getting bound up inside the "ordered" scope, which means we can now have a simpler/better/more natural implementation of default scoping. A knock on effect is that some things that didn't work properly now do. For example it was previously impossible to use #except to remove a part of the default scope, since the default scope was evaluated after the call to #except.
-
- 14 6月, 2013 1 次提交
-
-
由 Vijay Dev 提交于
-
- 13 6月, 2013 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 10 6月, 2013 2 次提交
-
-
由 Dmitry Polushkin 提交于
-
由 Dmitry Polushkin 提交于
-
- 09 6月, 2013 3 次提交
-
-
由 Thiago Pinto 提交于
-
由 Thiago Pinto 提交于
-
由 Thiago Pinto 提交于
-
- 11 5月, 2013 1 次提交
-
-
由 Ben Woosley 提交于
Rather than raising ThrowResult when construct_limited_ids_conditions comes up empty, set the relation to NullRelation and rely on its results. This will help avoid errors like 2fcafee2, because in most cases NullRelation will do the right thing. Minor bonus is avoiding the use of exceptions for flow control.
-
- 10 5月, 2013 8 次提交
-
-
由 Ben Woosley 提交于
-
由 Ben Woosley 提交于
In #apply_join_dependency, we can apply the #where in-place because relation is always a new object. Thanks to the #except we call at the top of the method.
-
由 Ben Woosley 提交于
-
由 Ben Woosley 提交于
-
由 Ben Woosley 提交于
-
由 Ben Woosley 提交于
Move the except(:select) inside the construct_limited_ids_condition method to pair it closely with its motivation.
-
由 Ben Woosley 提交于
Reject blank order_values within #columns_for_distinct, as the orders aren't used at all on non-postgres adapters.
-
由 Ben Woosley 提交于
The combination of a :uniq => true association and the #distinct call in #construct_limited_ids_condition combine to create invalid SQL, because we're explicitly selecting DISTINCT, and also sending #distinct on to AREL, via the relation#distinct_value. Rather than build a select distinct clause in #construct_limited_ids_condition, I set #distinct! and pass just the columns into the select statement. This requires introducing a #columns_for_distinct method to return the select columns but not the statement itself.
-
- 03 4月, 2013 1 次提交
-
-
由 Steve Klabnik 提交于
-
- 02 4月, 2013 1 次提交
-
-
由 wangjohn 提交于
inverse_of option. I've also refactored the code for raising a RecordNotFound exception when searching for records with ids.
-
- 27 3月, 2013 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
-
- 18 3月, 2013 1 次提交
-
-
由 Carson McDonald 提交于
[ci skip]
-
- 24 2月, 2013 1 次提交
-
-
由 Xavier Noria 提交于
-
- 04 12月, 2012 1 次提交
-
-
由 Yves Senn 提交于
Closes #3313
-
- 10 11月, 2012 1 次提交
-
-
由 AvnerCohen 提交于
-
- 08 11月, 2012 3 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
由 Carlos Antonio da Silva 提交于
-
由 Carlos Antonio da Silva 提交于
This is already handled by #find, it's a duplicate check, since find_with_ids is not called from anywhere else.
-
- 26 10月, 2012 1 次提交
-
-
由 Jon Leighton 提交于
In the end I think the pain of implementing this seamlessly was not worth the gain provided. The intention was that it would allow plain ruby objects that might not live in your main application to be subclassed and have persistence mixed in. But I've decided that the benefit of doing that is not worth the amount of complexity that the implementation introduced.
-
- 03 8月, 2012 1 次提交
-
-
由 Xavier Noria 提交于
-
- 31 7月, 2012 1 次提交
-
-
由 Bogdan Gusiev 提交于
User.order("name asc").order("created_at desc") # SELECT * FROM users ORDER BY created_at desc, name asc This also affects order defined in `default_scope` or any kind of associations.
-
- 28 7月, 2012 1 次提交
-
-
由 Jon Leighton 提交于
It has been moved to active_record_deprecated_finders. Use #to_a instead.
-
- 29 6月, 2012 1 次提交
-
-
由 Francesco Rodriguez 提交于
-
- 25 6月, 2012 1 次提交
-
-
由 Egor Lynko 提交于
`FinderMethods#exists?` finder method now returns *false* with the *false* argument
-
- 11 6月, 2012 4 次提交
-
-
由 Yasuo Honda 提交于
-
由 Ben Woosley 提交于
reflection. ActiveRecord::FinderMethods#construct_limited_ids_condition will raise ThrowResult if the limited reflection comes back empty. The other callers of #construct_limited_ids_condition handle this exception (more specifically, the callers of construct_relation_for*), but #exists? didn't until now.
-
由 Rafael Mendonça França 提交于
This behavior was added in be4ecdcc. Closes #1139. Fixes #2553, #1141, #1623 and #2062.
-
由 iaddict 提交于
Minimal change to query generation of exists? that makes SQLServer and others happy that do not work without a column alias. Conflicts: activerecord/lib/active_record/relation/finder_methods.rb
-
- 28 5月, 2012 1 次提交
-
-
由 Francesco Rodriguez 提交于
-