| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
the connection
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 257fa6897d9c85da16b7c9fcb4ae3008198d320e, reversing
changes made to 94725b81f5588e4b0f43222c4f142c3135941b4b.
The build failed
https://travis-ci.org/rails/rails/builds/7883546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an SQL improvement to ActiveRecord::Relation#blank?. Currently,
it calls `to_a` on the Relation, which loads all records in the
association, and calls `blank?` on the loaded Array. There are other
ways, however, to check the emptiness of an association that are far
more performant. `#empty?`, `#exists?` and `#any?` all attach a `LIMIT
1` to the SQL query before firing it off, which is a nice query
improvement. `#blank?` should do the same!
Bonus performance improvements will also happen for `#present?`, which
merely calls the negation of `#blank?`
Signed-off-by: David Celis <me@davidcel.is>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Inspect uses double quotes.
* Inspect puts a hash as in #<User ...>.
* Documents the return value, and makes explicit it can be an invalid record.
* Documents the method is not atomic.
* Documents a way to handle UNIQUE contraint violations in the event of a race condition.
* Removes the "Examples" header according to our guidelines.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
deprecated
Fixes activerecord-deprecated_finders build.
https://travis-ci.org/rails/activerecord-deprecated_finders/builds/5964703
|
| |
|
| |
|
|
|
|
| |
Closes #9712.
|
|
|
|
|
|
|
|
| |
The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.
There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.
|
|
|
|
| |
public API.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We discussed that the auto explain feature is rarely used.
This PR removes only the automatic explain. You can still display
the explain output for any given relation using `ActiveRecord::Relation#explain`.
As a side-effect this should also fix the connection problem during
asset compilation (#9385). The auto explain initializer in the `ActiveRecord::Railtie`
forced a connection.
|
|
|
|
|
|
|
|
| |
* User class instead of Users.
* #where_values_hash does not change the value to downcase as the
example was showing.
[ci skip]
|
|
|
|
|
|
|
|
|
| |
in a default_scope.
`Model.joins(...).where(condition_on_joined_table).update_all` /
`delete_all` worked, but the same operation implemented with a
default_scope generated a SQL error because ActiveRecord ignored the
join but implemented the where condition anyways.
|
| |
|
|
|
|
|
|
|
|
| |
They was extracted from a plugin.
See https://github.com/rails/rails-observers
[Rafael Mendonça França + Steve Klabnik]
|
| |
|
| |
|
|
|
|
| |
to keep 'output' messages untouched.
|
| |
|
|
|
|
|
|
|
| |
This is similar to #first_or_create, but slightly different and a nicer
API. See the CHANGELOG/docs in the commit.
Fixes #7853
|
|
|
|
| |
https://bugs.ruby-lang.org/issues/7166
|
| |
|
|\
| |
| | |
AR::Relation#model would be a better API than AR::Relation#klass
|
| | |
|
|\ \
| | |
| | |
| | | |
Change Relation#update_all with blank argument to raise an ArgumentError
instead of trying an update with empty fields.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This doesn't change the exernal behavior, but it moves some code around
to where I think it properly belongs.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This method explicitly loads the records and then returns `self`.
Rather than deciding between "do I want an array or a relation?",
most people are actually asking themselves "do I want to eager load
or lazy load?" Therefore, this method provides a way to explicitly
eager-load without having to switch from a `Relation` to an array.
Example:
@posts = Post.where(published: true).load
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A test was failing due to the way that Relation#inspect causes
association proxies to ignore unsaved records added to the association.
This is fixed by simply calling to_a and letting to_a figure out how to
get the records (which, in the case of associations, takes into account
new records).
I think it is acceptable to do this rather than limiting the query at
the database level:
* It's what we've done in all released Rails versions up to this point
* The goal of the limit is to not flood the console with output - this
is the problem we're targeting, rather than the actual loading of the
records from the database
* You probably want to do something with those records later anyway,
otherwise you wouldn't have built a relation for them.
|