| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |\
| | |
| | | |
Includes with persistent select, fixes #11773
|
| | |
| | |
| | |
| | | |
was overwritten.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
I don't really like passing the block, but this seems easiest for now
|
| | | |
|
| | | |
|
|/ / |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression. The documentation said in its introduction
paragraph that the method returns truthy/falsy, but then below it
was said that if there were no arguments you'd get `true` or `false`.
Also when the argument is exactly `false` a singleton is documented
to be returned.
The method was not returning the singletons so it didn't conform to
those special cases.
The best solution here seems to be to just return singletons in all
cases. This solution is backwards compatible. Also, the contract
has been revised because it has no sense that the predicate varies
that way depending on the input. I bet the previous contract was just
an accident, not something mixed on purpose.
Conflicts:
activerecord/lib/active_record/relation/finder_methods.rb
activerecord/test/cases/finder_test.rb
|
| |
|
| |
|
|
|
|
| |
Perf ref: https://gist.github.com/vipulnsward/8209749201dfdd678c97
|
|
|
|
|
|
|
|
|
|
| |
In 94924dc32baf78f13e289172534c2e71c9c8cade 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Refactored ActiveRecord `first` method to get rid of duplication.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
guides/source/upgrading_ruby_on_rails.md
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| | |
up empty, set the relation to NullRelation and rely on its results.
This will help avoid errors like 2fcafee250ee2, because in most cases NullRelation will do the right thing. Minor bonus is avoiding the use of exceptions for flow control.
|
| |
| |
| |
| | |
#join_associations.
|
| |
| |
| |
| |
| |
| | |
is always a new object.
Thanks to the #except we call at the top of the method.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
to pair it closely with its motivation.
|
| |
| |
| |
| | |
used at all on non-postgres adapters.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
inverse_of option. I've also refactored the code for raising a
RecordNotFound exception when searching for records with ids.
|
| | |
|
|/ |
|
|
|
|
| |
Closes #3313
|
|\
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_dispatch/routing/redirection.rb
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
| |
This is already handled by #find, it's a duplicate check, since
find_with_ids is not called from anywhere else.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
It has been moved to active_record_deprecated_finders.
Use #to_a instead.
|
|\
| |
| |
| |
| | |
Conflicts:
activemodel/lib/active_model/errors.rb
|
| | |
|